Forgot your password?
typodupeerror

Comment: Re:Which site "collapses"? (Score 1) 107

by tepples (#47811429) Attached to: New HTML Picture Element To Make Future Web Faster
AnandTech has the same problem as NCSA: the transition from three columns to two is placed too close to the 1024px mark, causing a "snapped" window on a 1920x1080 pixel display to use a jarringly different layout. I guess they had to do this because the About / Advertising / Bench line and the Trending Topics line are too tightly packed for any sort of flexibility. The Verge has distinct three-, two-, and one column layouts, but they're visually consistent and on the whole no less jarring than what you might expect if you resized an old-skool liquid layout like Slashdot classic's comment pages between the full width of a 1920x1080 display and half the width.

Comment: Mashable sucks in other ways too (Score 1) 107

by tepples (#47811255) Attached to: New HTML Picture Element To Make Future Web Faster

Yeah, I see the problems you point out with Mashable's front page in Firefox at 500-1024px, and I agree with you that Mashable is doing it wrong. But those are fixable problems if only Mashable management had the sense to correct the design. You're not claiming that the very opportunity to do width transitions wrong justifies removing the media queries feature entirely, are you?

Anyway, badly done viewport width transitions are consistent with other problems I see on Mashable, such as that damn "infinite scrolling". I think infinite scrolling is a crock of $#!+ on desktop; the scrollbar control just wasn't designed for it. Give me defined pages any day of the week. Literally. Just give me a page for each date so that I can link to the collection of stories that the site ran on a particular day (or week or month for a less busy site).

Comment: NCSA is doing it wrong (Score 1) 107

by tepples (#47811117) Attached to: New HTML Picture Element To Make Future Web Faster
Ouch. That transition from 2 columns to 1 is so close to 1024px it sickens me. Even a browser window snapped to half of a 1920x1080 screen, or a user of a 1024x600px netbook whose scroll bars are set just wider than normal, would get the 1-column layout with a hamburger menu on the front page of NCSA's web site.

Comment: Re:Which site "collapses"? (Score 1) 107

by tepples (#47811061) Attached to: New HTML Picture Element To Make Future Web Faster
On the front page of FiatTech.com, I don't especially see what's wrong with what appears to be a fairly predictable switch from a 2-column layout to a 1-column layout around 750px. Is horizontal scrolling really better? Or should it have been using the 1-column layout in the first place for all screen sizes?

Comment: Re:Which site "collapses"? (Score 1) 107

by tepples (#47811043) Attached to: New HTML Picture Element To Make Future Web Faster
The front page of Porsche USA isn't that bad in my testing (from about 500px to 1024px wide). Things get put in more or fewer columns, but that's similar to what happens to text in any liquid layout. The most drastic changes are the layout of the "Build & Find" menus near the bottom below about 500px and the addition of a "hamburger" menu at the top below about 700px.

Comment: Layne's Law break: "semantic value" (Score 1) 107

by tepples (#47810967) Attached to: New HTML Picture Element To Make Future Web Faster

Images themselves have no semantic value

I detect definition disagreement, and this thread can't usefully continue until we clear this up. I'm unfamiliar with the definition of "semantic value" that you're using. Is it from a standard? If so, which?

You wouldn't invent a redundant element for audio files

Except they did just that. The audio element allows specifying multiple otherwise equivalent sources, each in a source element, so that the browser can choose the most technically appropriate one. This allows letting the browser choose, say, an MPEG-family format if it's an Apple or Microsoft browser or a royalty-free format if it's a third-party browser.

Comment: Re:Window size and pixel density in what header? (Score 1) 107

by tepples (#47810891) Attached to: New HTML Picture Element To Make Future Web Faster

Pixel density: Since user-agent has been available

A single combination of web browser and operating system can be used on both low DPI displays and high DPI displays. Consider, for example, Safari on a MacBook with a Retina brand high DPI display and Safari on a MacBook with a normal DPI display.

Window size: This is not something you should be using. That's something the browser uses to reflow properly designed content

So if the web page's style sheet specifies that a particular image shall be 50 percent of the width of the viewport, however wide the user might have chosen to make that, how should the server go about determining how many pixels that is in order to serve the correct amount of image detail?

Comment: Overhead of dozens of requests (Score 1) 107

by tepples (#47810805) Attached to: New HTML Picture Element To Make Future Web Faster
Sending a separate request for each 10,000 byte chunk of the picture will increase latency, as the browser has to look at each downloaded chunk and decode it to see whether it should send another request. It'll also burn through more of the user's data plan as the request headers and response headers are resent for each chunk. How should the browser estimate how big the chunk should be for a given pixel count?

Comment: Offline browsing (Score 1) 107

by tepples (#47810685) Attached to: New HTML Picture Element To Make Future Web Faster
I agree that images for the foreground page should be prioritized. But not loading images for background tabs at all would break offline use. Consider someone who loads up on web pages to read on a laptop before boarding a bus: load tabs in the background, close the lid to put it in suspend, board the bus, open the lid, and then view the pages.

There's no such thing as a free lunch. -- Milton Friendman

Working...