Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Wed, Jun 06, 2012 at 07:32:34PM -0500, Glenn Maynard wrote: Please don't encourage yet more sites to open new tabs when I didn't ask for it. It's merely a new browsing context IIUC, not necessarily a new window (frame, tab, tile or whatever it's called this year). Someone that understands the codebase of a modern browser could even make the back button work, although he would have to restrict write access to the history stack or tree as well, for security reasons.
Re: [whatwg] register*Handler and Web Intents
On Mon, Apr 02, 2012, Ian Hickson wrote: On Tue, 21 Feb 2012, Bjartur Thorlacius wrote: Windows Explorer (the file manager) does for example offer users to edit images upon right-click. I worry that if URI scheme handlers need not only take care of fetching but also of presentation, other actions than view will be unnecessarily hard to implement. Thus I figure retrieval and presentation must be separated. I don't really see how you would tell the browser what the action is. Users can select actions from context menus. The context menus are populated with the registered actions applicable for the context resource (filtered using the media type as a criterion). Example (just skip it if the above is clear): 1. An UA registers an intent (e.g. as found in an intent tag) 2. The UA embeds an image in an interactive document rendering for an user 3. The user opens a menu of actions pertaining to the image: * view (in original resolution) * share (on Flickr, via email, or using Bittorrent and an entry in The Pirate Bay) * edit (using either Photoshop or Gimp) 4. The user selects the edit menu, and thereunder Photoshop. The only attribute of network protocols that is of concern to most users is authentication. Many also care about encryption. Everything else is a technical detail that should be completely transparent, both to users and composers and viewers.
Re: [whatwg] picture / img srcset not needed
On Wed, May 16, 2012 at 07:46:54AM +0200, Anselm Hannemann Web Development
wrote:
The good thing on the picture element is that we have the possibility to
serve other image-crops and with that the meaning could change so we could
update the alt-attribute in the tag for every source-element.
I do know this is a very special case but valid: An image displayed for a
desktop while a monochrome display will get an drawing / shape-image instead.
This has the very much same meaning but a different content and has to have a
different description in alt-attribute IMO.
How common will it be for modern UAs to render pages to monochrome displays
using future HTML5 graphics features? How many of the monochrome displays that
are left will be attached to systems with modern heavy-weight software? In
fact, the only systems I know of that come close to being monochrome are
handhelds whose software isn't ever updated, and terminals that aren't even
used to display bitmaps. So I have to ask, for how long will color-depth
negotiation be a strong enough use case to warrant this feature?
Another thing is: We do not have any graphic editor to do such things you
have described yet. So you have to write this on your own along with SVG
polyfills etc.
This is a valid solution but won't work for the masses of developers. Please,
always think of the millions of HTML-developers who only want to do a normal
cool website using responsive images.
A significant portion of the masses will be dependent on new GUI, whichever
solution we choose. The following CSS SVG wouldn't be created by an image
manipulation program; it would most likely be generated by CMSs. That's
equivalent to UAs themselves adapting images to their viewport, aside from
bandwidth and CPU savings.
Am 16.05.2012 um 03:23 schrieb Aldrik Dunbar:
?xml version=1.0 encoding=UTF-8?
svg xmlns=http://www.w3.org/2000/svg; viewBox=0 0 900 1135
descA painting by Edvard Munch, commonly known as the scream./desc
style type=text/css ![CDATA[
svg { background-size: 100% 100%; }
@media (min-width:477px) {
svg { background-image:
url(https://upload.wikimedia.org/wikipedia/en/f/f4/The_Scream.jpg;); }
}
@media (max-width:476px) {
svg { background-image:
url(https://upload.wikimedia.org/wikipedia/en/thumb/f/f4/The_Scream.jpg/476px-The_Scream.jpg;);
}
}
]]/style
/svg
Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)
On 5/13/12, Kornel Lesiński kor...@geekhood.net wrote: I think layout (media queries) and optimisation cases are orthogonal and it would be a mistake to do both with the same mechanism. My knee-jerk reaction to the above thought is that layout should be done using CSS and any optimizations left up to the UA. A bandwidth constrained UA could request a downsized thumbnail that fits the size of the object/img/video poster/a element, or render an appropriately sized bitmap from a SVG. The problem with that, though, is that then bandwidth constraints can't affect layout. Users should be able to configure UAs to use downsized images even given a large viewport, if only to save bandwidth and reserve a larger fraction of the viewport for text columns. Adaptation of images to the layout is page-specific. Adaptation of images to bandwidth/screen is UA/device-specific. Quite. But the latter just might affect the layout. Author is in the best position to adapt image to page layout. User-agent is in the best position to determine speed/quality trade-offs. But low-res images usually don't look too good when upscaled. Thus few pixels should mean small image, UAs mustn't default to pixelation. Media queries MUST be interpreted exactly as author specified them. Thus we mustn't force UAs to pretend to render to small viewports to find low-res images. That would have unwieldy side-effects. User-agents need freedom to choose image resolution based on open set of factors, many of which are details authors should not have to think about (presence in cache, cost of bandwidth, available memory, external displays, etc.) But the chosen image resolution might be a factor for choosing layout.
Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)
On 5/13/12, Kornel Lesiński kor...@geekhood.net wrote: By resolution I mean pixel density (regular vs Retina display), so this doesn't affect layout. Ah, I must have misunderstood you. I can imagine layout complexity being tied to bandwidth (an image-rich design vs minimalistic text-only design), but I'm not sure how that would work in practice given that cache has infinite bandwidth, and network speed can change any second on mobile connections. The layout would not depend directly on bandwidth, but on an upper limit on graphic-heaviness. It would be weird if page design changed when you moved between cell towers or left/entered a cafe that had public WiFi. And if bandwidth media query was defined to be fixed, then you'd sometimes end up stuck with wrong design that was chosen based on a temporary network state. There's no question that bandwidth media queries would be a bad idea. How would you measure bandwidth anyway? My thinnest downlink is a few Mb/s, but I'm charged an increasing amount for every 10Gb/mo of international downloads. Authors should of course not evaluate how important their graphics are to users against bandwidth scarcity (artificial or real). There is no such problem if only same-CSS-pixel-size images are swapped in-place. True. I've got a hunch I'm over-thinking this, but might bandwidth-constrained users not prefer miniatures instead of huge pixelated images?
Re: [whatwg] Search-suggestions without scripting
On 5/5/12, Ian Hickson i...@hixie.ch wrote: Note that even in this space, though, it's not the end of the story. For example, Chrome does more than just list the search autocomplete results; it also loads the first suggestion in the background, and mixes in results from local history search, etc. Other browsers do similar mixing. While this works well for browser UI, where the browser can mix in all the various results together, when you are talking about a Web page you still end up needing script to do that. So having it declarative isn't necessarily a win. Mixing multiple sources, such as user history and site suggestions, and automatically performing actions upon them, such as prefetch and prerender, should be easier for the user agent to do if the necessary information to do so is declared, no?
Re: [whatwg] Prerendering and APIs
On Wed, 14 Mar 2012 15:35:14 -, Gavin Peters (蓋文彼德斯) gav...@chromium.org wrote: We're having great luck in Chrome with link rel=prerender href=foo. If Does link rel=next href=doc2 not trigger this feature?
Re: [whatwg] Specify href target with HTTP headers
On Wed, 14 Mar 2012 19:59:50 -, Christian Schmidt whatwg@chsc.dk wrote: Bjartur Thorlacius skrev 2012-03-09 10:43: I argue that putting user interface hints into a file transfer protocol does cause problems Would it be better if the Window-Target was somehow specified in the head of the destination page, or is that just another way of doing the same? In special, having two identifiers for the same resource, one for when the resource is to be navigated to in an existing browsing context and another for when navigation to the resource implies creation of a new browsing context, breaks identification. It was not my suggestion to use to introduce more URLs. But a resource that is designed to be used in an iframe context often does not make sense to load in the entire browser window (pages loaded in an iframe often do not contain navigation, header, footer etc.), so in practice I think a resource is often somewhat “tailored” to a specific browsing context. If the response (headers + page) are tailored to the specific browsing context already, Window-Target should not create any new problems. But do note that the streamlined presentation you describe makes sense for both projection and tiny viewports as well. In fact, link collections such as Wikipedia's toolbox are resources in and of themselves that are often embedded in pages (or included by proxies) to optimize out costly round-trips. Optimizing for iframes is mostly about trimming non-(main)-content. (For the record, I hunt for made-for-iframes pages, such as the Facebook chat pop-out, and load them in a dedicated window to avoid clutter. I simply prefer UI that minimizes the amount of on-screen distractions.) I'm not sure I understand what you mean. The usual way of doing server-side validation of a form (e.g. a login form) is to submit it and - in case the validation fails - to show the same form prefilled with the same data but with red boxes around the invalid fields, error messages, help texts, etc. Of course you can do this by submitting the form via AJAX and then manipulate the DOM via JavaScript, but that is complex. I agree with all of the above. I find it notable that user agents have not standardized on and implemented a form submit and validation protocol that every AJAX page reimplements already. The reason is probably because implementing said protocol would probably be more difficult to implement in user agents, and harder to style by servers for branding reasons. While I find it notable, I do not volunteer to change this. It would most likely not be worth the effort. -- -,Bjartur
Re: [whatwg] Specify href target with HTTP headers
On 3/8/12, Christian Schmidt whatwg@chsc.dk wrote: AFAIK no modern browser implements Window-Target, so I don't think the we need to reuse the old header name. Expanding Content-Disposition is also an option, e.g. Content-Disposition: inline; target=_blank. Unfortunately we cannot use Content-Disposition: _blank, because unknown values (not attachment or inline) are treated as attachment (RFC 2183, section 2.8). Separating the network protocol from the user interface seems highly desirable. Window-Target sacrifices that. I get your point. But it seems that Content-Disposition already suffers from this. Yes, it does. In fact servers often reply with Content-Disposition: attachment given a query of download=yes. Make note of the thread discussing a Content-Disposition attribute of A. I argue that putting user interface hints into a file transfer protocol does cause problems. In special, having two identifiers for the same resource, one for when the resource is to be navigated to in an existing browsing context and another for when navigation to the resource implies creation of a new browsing context, breaks identification. It may depend on something external, e.g. the submitted form values (e.g. username and password) compared against an external database, so it cannot be determined without actually submitting the form. I don't know if my pie in the sky thought should be taken seriously, but why would I want another copy of the form I just submitted? I just want the error messages.
Re: [whatwg] Specify href target with HTTP headers
On Wed, 07 Mar 2012 22:19:17 -, Christian Schmidt whatwg@chsc.dk wrote: I suggest that a server can specify a link target in an HTTP header, e.g. Window-Target: _blank. The page would be equivalent to specifying the same value in the form or a tag leading to the page. It should probably be subject to some kind of restrictions, e.g. the header could be ignored if the link destination and the referring page had different origins, unless the referring page specified some special value in the target, e.g. _server (this value would indicate that the link destination is a somewhat trusted resource whose Window-Target header should be honoured). This ensures that the referring origin is always in control of the target. We should describe the security implications of lifting said restrictions (if any) in the rationale document, for when someone is burdened by these restrictions and can't figure if they were added for erring on the side of security or to address some specific security problems. It seems there was such a header (to some extent, at least) back in Netscape 4: http://lists.w3.org/Archives/Public/www-html/1998Jan/0010.html https://bugzilla.mozilla.org/show_bug.cgi?id=97459 The Content-Disposition: attachment/inline header does something related not entirely. Its was originally invented for use in MIME mails. Content-Disposition seems like the correct header to use to me, but using the previously implemented header is fair enough. Window-Target and Content-Disposition must not appear in the same message, as the semantics of the former are a subset of the semantics of the latter AFAICT. Use-case #1: Sometimes the form target cannot be determined until after the form has been submitted. Assume you have a form of some kind. If the server-side validation fails, you want to load the same page again (this time with an error message) in the same window, but if the server-side validation succeeds, you want to open a new window, e.g. containting a PDF or some application-like window. This behaviour is sometimes done using window.open() on the target page, but many popup blockers prevent this. Separating the network protocol from the user interface seems highly desirable. Window-Target sacrifices that. Would it not be more appropriate to return an error response clearly marked as such? That, however, would leave the issue of connecting error messages to specific form fields. Use-case #2: In Drupal 8 the administrative pages are opened in an overlay/lightbox on top of the frontend pages. For each URL it is specified (by means of wildcard patterns in hook_admin_paths()) whether it should open in the overlay or in the entire browser window, i.e. whether the URL is an administrative page or not. For each link on a page the target attribute should be specified accordingly (this is handled client-side using a click handler on a elements that matches the current href against the wildcard patterns and dynamically alters the target attribute - see Drupal.overlay.eventhandlerOverrideLink in [2]). Contrary to use-case #1 it /is/ possible to preprocess all links, but it is a lot of work for all links on a page. It would be easier if the server could determine, whether the link that was actually clicked on should open in the overlay or not. Note that you can also annotate the links with target hints server-side when you serve the frontend pages. While Window-Target may not be a great solution to this problem, I can't think of a better one ATM. On a and form elements you can specify a target attribute, e.g. _blank. But sometimes you don't know whether to open in _self or _blank at the time the link is clicked/the form is submitted. The questions are, what information is necessary to decide whether to reuse the browsing context or not, and what other decisions depend on the said information? -- -,Bjartur
Re: [whatwg] a download feedback
Þann lau 3.mar 2012 21:30, skrifaði Glenn Maynard: Another use case: fixing Google's search results. They're currently annoyingly broken: [snip] Yes, Google is broken. But no, Save As is not the only thing that it breaks. In special, a href=http://www.google.com/url?sa=tamp;rct=jamp;q=l%C3%B6gbergamp;source=webamp;cd=2amp;ved=0CCwQFjABamp;url=http%3A%2F%2Fwww.thingvellir.is%2Fsaga%2Flogberg%2Famp;ei=F69ST6T3OM6XOqGOnZEKamp;usg=AFQjCNEPLku9Nm5bsA12_oY9mV1gPH3Aegamp;cad=rja; ... does not link to http://www.thingvellir.is/saga/logberg/. Google could fix this by linking directly. That, however, would allow for opting out of tracking by simply not running scripts.
Re: [whatwg] including output in form submissions
On Feb 24, 2012, at 12:18 AM, Michael Gratton wrote: But in general, I recommend against this. Anything that can be computed should be computed on the server to obtain the canonical value, otherwise you open yourself up to attackers sending you inconsistent data. While for applications where trust is an issue one clearly needs to check calculations server-side. When it is not however, this would be a welcome addition. The principle of least authority applies. In general, neither the client nor the link he communicates over should not be trusted unnecessarily.
Re: [whatwg] Proposal: Deprecate registerProtocolHandler/registerContentHandler via Web Intents
Þann mið 15.feb 2012 23:39, skrifaði James Hawkins: * If |scheme| is specified, |action| *should* (must?) be ignored. Why would you forbid distinguishing between actions on URIs? Postal and retrieval of mail, for example, are quite distinct actions. As are modification and retrieval of documents.
Re: [whatwg] Proposal: Deprecate registerProtocolHandler/registerContentHandler via Web Intents
Þann þri 21.feb 2012 18:44, skrifaði James Hawkins: I'm not sure if the proposal was explicit enough, but for the RPH-esque functionality in Web Intents, we activate WI in the same circumstances RPH is activated, which is when links are activated in a page. Can you elucidate how the scenarios you listed could be handled? Note these scenarios are above and beyond RPH, but we're not trying to make the API self-limiting. Windows Explorer (the file manager) does for example offer users to edit images upon right-click. I worry that if URI scheme handlers need not only take care of fetching but also of presentation, other actions than view will be unnecessarily hard to implement. Thus I figure retrieval and presentation must be separated. (view (fetch uniform:resource/locator)) or (edit (fetch uniform:resource/locator)) instead of (fetch-and-view uniform:resource/locator)
Re: [whatwg] Proposal: Deprecate registerProtocolHandler/registerContentHandler via Web Intents
Þann þri 21.feb 2012 19:41, skrifaði James Hawkins: Is this use case not fully handled by the UA specifying the appropriate action when building the intent, e.g., the user right-clicks on an image in a page and the UA constructs context menu items for edit/share/etc. action? Not if the image is both fetched and drawn by a single plugin. By plugin I mean an extra-UA piece of software that is allocated a window to draw to. I hope you meant that an Intent API could be used to pass URIs to fetchers to pass back retrieved resources, without converting them to HTML or bitmaps, rather than to pass URIs of resources to be drawn to users' screens or speakers.
Re: [whatwg] Caching of identical files from different URLs using checksums
Þann lau 18.feb 2012 13:45, skrifaði Sven Neuhaus:
The relevant section from RFC 3986 reads:
The fragment identifier component of a URI allows indirect
identification of a secondary resource by reference to a primary
resource and additional identifying information. The identified
secondary resource may be some portion or subset of the primary
resource, some view on representations of the primary resource, or
some other resource defined or described by those representations.
This description is not contradicting the use of checksum as fragment
identifiers. They are additional identifying information.
I beg to differ. I interpret the RFC as stating that the fragment
identifier allows indirect identification of a secondary resource. The
fragment identifier itself is whatever information is needed to derive
the secondary resource from the primary resource. That is, you need
*both* a reference to a primary resource (i.e. an URI with no fragment
identifier) and additional identifying information (i.e. the fragment
identifier).
The fragment identifier component of a URI allows indirect
identification of a secondary resource by {reference to a primary
resource and additional identifying information}.
A checksum of (a representation body of) the primary resource identifies
(said representation body of) the primary resource, not any secondary
resource derived therefrom.
And as has been pointed out previously, representations of resources are
frequently obsoleted. Existing caching mechanism take care of that
already, without requiring every reference to be updated on every
obsolete. The problem you have mentioned is duplicate identifiers (that
undermine the very raison d'être of identifiers).
Another solution would be to add a host attribute to linking elements
(script, link, etc) that specifies a domain name of an endorsed CDN that
will serve the resource (and ideally a public key). HTTP/1.1 mandates
support for but forbids requests of the form METHOD URI HTTP/1.0.
IIRC the current RFC forbids, but mandates support for, such requests.
The seventeenth httpbis draft OTOH explicitly allows absolute URI in
request lines, at least to proxies.
bjartur@gamla ~ $ nc google.org 80
GET http://www.google.is/ HTTP/1.0
HTTP/1.0 200 OK
Re: [whatwg] Deferring image load
On 2/13/12, Gray Zhang otakus...@gmail.com wrote: We would like to present an authoring difficulty with regard to showing images on the Web with limited bandwidth, when deferring loading of certain or all images are preferable. We have some vague ideas about what browser/markup solutions instead of script solutions might look like, but we are more interested in having the problems solved. Scenario 1. On a product description page of a shopping site, there are several *main* pictures of the product, along with about twenty or so camera pictures of the product taken from different angles. When the HTML is parsed, browsers by default simultaneously start downloading all images, potentially making some of the *main* ones invisible. Hmm. So you request a way to declare which images are important, and wich are not? 2. On an album page where hundreds of pictures are expected to be shown, it is often required that pictures currently in a user's screen should appear as fast as possible. Loading of a picture outside the screen can be deferred to the time that the picture enters or is about to enter the screen, for the purpose of optimization user experience. This seems like something interactive user agents should implement. 3. For a site with limited bandwidth on the server side, it is preferable to minimize the amount of data transferred per each page view. 70% of the users only read the first screen and hence pictures outside the first screen don't need to be downloaded before the user starts to scroll the page. This is to reduce server-side cost. 1. the @defer attribute on img and iframe 2. the similar @deferpolicy attribute with value a combination of visible, network-idle and render-idle 3. a global switch as a http header or an attribute on html to switch UAs image loading from obtain images immediately to obtain on demand or vice versa. Would this not depend equally on factors such as whether the user agent would download the images over a metered connection?
Re: [whatwg] Deferring image load
On Mon, 13 Feb 2012 11:00:52 -, Kang-Hao (Kenny) Lu kennyl...@csail.mit.edu wrote: Could you elaborate a little more on this? What is a metered connection? Not all network links are equally expensive. I have to pay for tens of gigabytes I send or receive over submarine or mobile wireless links. Paying three cents per megabyte over mobile wireless links is not too uncommon. OTOH, only a flat connection and service fee is payed for sending and receiving traffic over domestic copper and fiber. I don't know whether this is something UAs should bother catering to if bandwidth only goes up. -- -,Bjartur
Re: [whatwg] Deferring image load
On Mon, 13 Feb 2012 14:17:28 -, Boris Zbarsky bzbar...@mit.edu wrote: This is a difficult optimization to make. You can only do it for images that have a height and width specified in the markup, and worse yet it leads to pretty bad flicker as the user scrolls (because network roundtrip times are measured in hundreds of milliseconds to seconds). So doing this by default is not likely to happen. Having a page opt into it is a different story, though. Well, UAs would fetch the images to be displayed first first, and then prefetch images until they have more than a screenful of undisplayed content loaded. But yes, fast scrolling would break this. Not even knowing the rough size of images before fetching them makes them hard to lay out until they have been downloaded. -- -,Bjartur
Re: [whatwg] Deferring image load
On Mon, 13 Feb 2012 14:59:09 -, Boris Zbarsky bzbar...@mit.edu wrote: Well, UAs would fetch the images to be displayed first first, and then prefetch images until they have more than a screenful of undisplayed content loaded. What does screenful of undisplayed content mean for some slide-deck site that just moves images in and out of view via script? I would /expect/ such sites to use a static set of imgs dynamically pointed to prefetched link rel=prefetch images. With emphasis on expect. Opera devs should be more knowledgeable on the compatibility problems this raises, considered they have partly backed out of deferring image loading already. Not knowing the size makes it _impossible_ to do layout correctly. Again, UAs would only be able to skip getting images that have explicit height and width attributes. On the contrary, if you've laid out two screenfuls you can guess that anything after that will not be in the aforeoutlaid* screenfuls. And even then, things could be troublesome if the pseudo-clases for detecting loading state are added, since those could affect layout... As I say, there are numerous compatibility problems. If image dimensions late in the document affect the layout of a previous part of the document, as you seem to hint at, then hell is loose if we don't know them. Guessing would be most unfortunate and surprising to layout designers. * Well, the word does at least conform to the grammar of my native language :/ -- -,Bjartur
Re: [whatwg] Deferring image load
On Mon, 13 Feb 2012 19:12:09 -, Boris Zbarsky bzbar...@mit.edu wrote: On the contrary, if you've laid out two screenfuls you can guess that anything after that will not be in the aforeoutlaid* screenfuls. I wasn't talking about guessing at visibility. I was talking stuff like this: !doctype html div style=height: 100vh/div img src=something div style=position: relative; top: -50vh/div Where should that second div be placed? Should the user be able to see it? You don't know until you know the image size. In this case, User agents would obviously need to test if the latter div would be visible if the image was monopixel. Such complications would be bound to add up as we take more features into account; the optimization may well not be worth the complexity. And it gets even worse when tables are involved, because an image arbitrarily far down the table can affect the table column widths and the width of the whole table and the site probably depends on particular widths. I surrender to broken websites. -- -,Bjartur
Re: [whatwg] add html-attribute for responsive images
On Wed, 08 Feb 2012 17:16:36 -, Anselm Hannemann - Novolo Designagentur ans...@novolo.de wrote: Okay, I talked with some disabled web developers and Accessibility experts today and talked about the proposal of markup in alt-text. This seems not to be a good idea as screenreader would read the tags which would confuse many users then. So we would get into trouble with that approach according to current screenreader features, etc. This applies only to attributes. Elements can and do have element children, while attributes can only contain plain text. We should not redefine the alt attribute. A new element has been proposed in the list whose contents can be defined to be an alternative representation of the linked resource. Preferably we could just reuse elements and semantics where appropriate. Object data=lolcats.gif title=An animated image macro of mine type=image/gif pbNazi Cats/b/p pHumans have been obsoleted./p /Object Object data=lolcat.gif title=An animated image macro of mine type=image/gif Img src=lolcat.jpeg title=An image macro of mine alt=Nazi Cats. Humans are now obsolete. /Object As has been pointed out in the thread already, using object fallbacks of different media types may result in strange behavior, and is hard to implement correctly.
Re: [whatwg] add html-attribute for responsive images
If using a single object element for embedding in general would be too hard on implementations (although the markup cleanliness is tempting), can we not (re)use video for both animated and still 2D images?
Re: [whatwg] add html-attribute for responsive images
On 2/7/12, Ashley Sheridan a...@ashleysheridan.co.uk wrote: The main problem I see with that is that the object tag doesn't have the same accessibility attributes, so you'd effectively lock out a lot of people using browsers that don't understand the context of the tag in this case. I think the better way is to add something to the img tag as you'd still have full backwards compatibility. What accessibility features, exactly? For compatibility, the deepest child of object would be img alt, inheriting the accessibility features of img. Alternatively, it might just as well be markup, which is surely better accessibility wise than @alt and @longdesc. Furthermore, you could theoretically link to an animation, a still and a sound and embed a hypertext fallback. (I'm sorry if object's being generally terrible for accessibility has been established already.)
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header
On Mon, 06 Feb 2012 17:44:30 -, Boris Zbarsky bzbar...@mit.edu wrote: Yes, indeed. Supports touch input on multiple spots at once vs supports only a mouse seems like a much more important distinction than the nominal CSS pixel size of the screen I think CSS media queries could be extended to express multitouch capabilities. I don't think that would be useful for documents, but it could allow for per-device reimplementation of zoom and scroll. I'll leave deciding whether that's a fair use case to others. But that still doesn't warrant requesting different content. -- -,Bjartur
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header
On Mon, 06 Feb 2012 18:58:00 -, Boris Zbarsky bzbar...@mit.edu wrote: Again, it's not constant in the terms that the page sees, which are CSS pixels, not device pixels. We're discussing HTTP here, so the content might just as well be raster bitmaps. Multiple and variable screen dimensions are quite common (in special for projection). That means a request for every screen the resource may be. For legacy HTTP servers that don't support the new and complicated If-Different-For-Device header that would have to be added would serve the same content once for every screen. So you have UAs sending extra headers with every request, making extra requests with even more extra headers in the fairly common case of variable screen dimensions (multiple screens) and either extra response headers for servers that use the feature (perfectly acceptable) and double round-trip lag (probably terrible) while the UA waits for the extra response header to check if there are alternative versions of the resource for differently sized screens and fetches the alternative version if there is one, or redundant fetching of *all* resources in proportion to the number of possible screen dimensions (assuming the best case of screen dimension being the only variable). This is frightening in so many ways. You're better off discussing some of the details on httpbis though, in special if you intend to propose this formally to the Internet Engineering Task Force. When bandwidth savings are more important than download speed, and for tremendous size deltas (such as for heavy graphics with available downsamples), please consider HTTP 300 Multiple Choices client side negotiation and linking to multiple representations of the same resource. -- -,Bjartur
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header
On Mon, 06 Feb 2012 13:49:35 -, Matthew Wilcox m...@matthewwilcox.com wrote: We need the server to know about the device. We need headers. We need renderings tailored to our devices. Device tailoring is best done by someone with access to the device in question. Judging how rendering is best done is up to the user, who should most of the time accept whatever default the device manufacturer (or whoever writes software for said device or class of devices) suggests. We need servers to serve content. -- -,Bjartur
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header
On Mon, 06 Feb 2012 18:59:14 -, Boris Zbarsky bzbar...@mit.edu wrote: That really depends on what the application is doing. Depending on input capabilities, you may want to have multiple pages instead of a single page for some sort of configuration setup, for example. Whether to use monolithic forms or paginated wizards is a presentation thing, that need not even have anything to do with HTTP. You can fetch half the monolithic form and fetch the rest when the user has filled in most of former half. Or you could fetch a whole form and paginate it. -- -,Bjartur
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header
On Mon, 06 Feb 2012 19:49:43 -, Boris Zbarsky bzbar...@mit.edu wrote: that need not even have anything to do with HTTP. You can fetch half the monolithic form and fetch the rest when the user has filled in most of [the] former half. Not without script. Or (fragment) Accept-Ranges (so a mobile device could request a moderate number of entries). The fallback and default of receiving the whole form seems graceful enough to me. -- -,Bjartur
Re: [whatwg] add html-attribute for responsive images
On Mon, 06 Feb 2012 21:23:37 -, Mathew Marquis m...@matmarquis.com wrote: I recently published a sum-up of our thinking at A List Apart ( http://www.alistapart.com/articles/responsive-images-how-they-almost-worked-and-what-we-need/ )—in short, using the video markup pattern as the inspiration, with the use of media attributes on the source elements to determine the rendered source, and the inclusion of an img--ideally a smaller image, to account for the lowest-common-denominator--as a fallback similar to the way Flash or an image might be used as a video fallback. Why not use a media attribute of object? That way you should get media type disambiguation for free. -- -,Bjartur
Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header
Feel free to propose e.g. Accept-Media to httpbis[1]. Bandwidth negotiation would be most useful. Do make note of the dynamic nature of many viewports* and the fact that user agents may wish to render resources to multiple medias. The latter is rare enough to tolerate an extra roundtrip. Resizing viewports, however, should ideally not require a roundtrip. For fast resizing, UAs must obtain layouts for all possible sizes before viewport resize. On fullscreen systems, these sizes might as few as one or two. Thing is, user agents could lay self-contained elements out recursively without author stylesheets. User agents are all around much better suited to laying out self-contained elements than authors are. User agents can dynamically and intelligently apply new styles customized for their viewport. All authors have to do is semantically use nav, aside and link (so UAs can place them consistently) and group their content. *Viewport: A window to which an user agent renders a document [2] 1: http://www.ietf.org/html.charters/httpbis-charter.html 2: http://www.w3.org/TR/CSS21/visuren.html#viewport
Re: [whatwg] Why won't you let us make our own HTML5 browsers?
On Wed, 01 Feb 2012 05:00:04 -, Brett Zamir bret...@yahoo.com wrote: It would let anyone with web skills to have full creative control over the browser UI which they can in turn easily share with others regardless of the host browser those people are using, and without the hassle of building and packaging browser-specific add-ons or executables, or forcing users to manage these executables. The facility of allowing such a tool to be written in a standard cross-browser language would encourage experimentation and choice, and ultimately, I believe, better and more tailored user experience. Am I correct in understanding your request as being for a standard browser engine API, secure sandboxing and better package management?
Re: [whatwg] Requests for new elements for comments
On Thu, 26 Jan 2012 21:43:07 -, Matthew Wilcox elven...@gmail.com wrote: Obviously this is not right - perhaps I'm not understanding your use case? Why would you want to specify an author as an attribute on the element? Not necessarily as an attribute, I would prefer an element. What is wrong with: article class=by-post-author pContent/p footer p class=authorWritten by: Person/p /footer /article Nothing tangible. It would serve my main use case of allowing articles by respected authors to be rendered before other articles or otherwise style them. I believe semantically stating authorship to be useful e.g. for searching a collection of documents for articles by a specific author, or conversely, blacklisting. Also, hCard fn allows for abbreviation of names I would find handy when screen space is scarce. But I guess those are less important than the first one.
Re: [whatwg] Requests for new elements for comments
On Wed, 25 Jan 2012 22:26:31 -, Ian Hickson i...@hixie.ch wrote: Actually, they are remarkably similar. I think it's anachronistic to consider that the utterances of the site owner are in some way distinct from the utterances of the site readers. While I do agree with you (for a change), identifying authors of articles is undeniably useful. First-posters in a thread or syndication may be styled differently from other posters, articles by authors of outer articles may be emphasized in some way, articles by certain authors may be omit, etc. I find no algorithm for identifying authors of articles in the spec. Should the value of the first href attribute in a footer be assumed to identify the author? That seems bound to break, early and often. -- -,Bjartur
Re: [whatwg] Requests for new elements for comments
Þann fim 26.jan 2012 14:48, skrifaði Matthew Wilcox: What's wrong with using a class on the article to identify the author stylistically? It's already identified semantically by having their name in the article itself, right (presumably in a footer too)? As in article class=asdf lolcats author-bjar...@spam.la? Because then the class would contain content. That would depend on a stylesheet containing the identifier of every poster on every page. Generating such stylesheets from content already marked up in a page in a nonstandard fashion seems hackish at best, and harmful to usability at worst. The situation only gets worse when you consider the different stylistic needs of various media. I might want the whole footer rendered to the relatively large desktop screen of mine, but omit everything but authors' name or identity on my handheld screen. Address, for example, should be hidden behind a menu button and the authors name displayed tersely. The best solution I can think of is stating normatively that hCard footers describe authors of the respected article or document. hCard does not, AFAIK, provide means to state URIs of authors, but indirect identification using email addresses should suffice. !DOCTYPE html titleExample of Semantically Marking up Authors of Documents/title article h1An Article Written by Bjartur/h1 pThis article was written to demonstrate how authorship might be marked up. I sure hope it's valid!/p footer class=hcard a class=fn email href=mailto:bjar...@spam.la;Bjartur Thorlacius/a /footer /article
Re: [whatwg] [html5] r6630 - [giow] (0) Define navigating to video and audio resources Fixing http://www.w3.o [...]
On Wed, 05 Oct 2011 17:37:22 -, Ian Hickson i...@hixie.ch wrote: On Wed, 5 Oct 2011, Simon Pieters wrote: video and audio should have controls= and autoplay= The spec allows browsers to do that (in fact it explicitly calls out autoplay=), but do we really want to require one or the other? I can see arguments for having only one or the other or both. Autoplaying is obviously subject to user preference, but I see no point in not providing controls (assuming the output rendering is interactive, of course). Theoretically speaking, those controls should of course be stylable. That that may well be difficult to implement, however.
Re: [whatwg] [html5] r6630 - [giow] (0) Define navigating to video and audio resources Fixing http://www.w3.o [...]
On Thu, 06 Oct 2011 17:56:23 -, Ian Hickson i...@hixie.ch wrote: The context here is how browsers display videos when you just navigate to a video file directly. Much as with navigating to images, where the spec says to use img but doesn't require or disallow extra features, such as the zoom feature most brosers provide, we here just say to use video, and then leave the UI up to the UA. Sorry, I was thinking about nested browsing contexts. But imgs don't have zoom attribute, even though some sites want their implementation of zooming to override the implementation in the user agent. But IIRC, that had been discussed before.
Re: [whatwg] Making selectionDirection platform-independent
On Mon, 26 Sep 2011 16:14:39 -, Philip Rogers p...@google.com wrote: It looks like editors using a textarea (such as codemirror) are currently working around this by not drawing a cursor when there is a selection. In ignorance of the specificatory problem you describe, this seems sane enough to me. Whether to draw or not to draw a curser when there's a selection should of course be up to users. I'll refrain from thinking about the behaviour of multiple selections.
Re: [whatwg] The placeholder attribute
Should @placeholder be renamed @eg, and used exclusively for example input? On Thu, Sep 22, 2011 at 11:53 PM, Bjartur Thorlacius svartma...@gmail.com wrote: The semantics of the placeholder and title attributes of inputs overlap slightly; the placeholder attribute may contain a hint to aid the user, while title is to contain other advisory text. I can think of two valid uses of placeholder: example value, and the text click here to type or enter search query here. The latter is obviously user interface that should be implemented by interactive user agents. Then there is the third use, use it as a title attribute (but with richer presentation). Users might want values falling under the first to be prefixed with e.g., for example or equivalent - but by allowing the latter use forces authors to add it to all example values, rather than letting the user's style sheet take care of it. Thus I suggest narrowing the semantics of the attribute to example values, allowing for easier styling by users (or agents, on their behalf). The second one should have no valid representation. Lastly, the specification should make it clearer what the title attribute is appropriate for; a description of the input or format. Also, I see no reason to suggest not rendering the text when the input is focused - in special on 1D devices such as speech - considering that JavaScript dependent sites (such as Hotmail) have placed example values in a small font below the input so that it can be visible while the user is typing, and, more importantly, after the input has been focused (whether automatically or manually), but before the user starts typing. As for the argument against using the title attribute for everything that it would break existing sites, I do believe rendering the title attribute of an empty and unfocused input inside of it is an improvement over displaying a tooltip a second or two after the user positions a cursor over the input (irrespective of focus). How on Earth is anyone to think of doing that? Displaying the title attribute in a floating box in a margin when an input is focused, followed by the example value prefixed with e.g. would be my preferred rendering, but that's just my opinion. P.S. The last paragraph of the section on the pattern attribute links twice to semantics.html#the-title-element. Should it not link to elements.html#the-title-attribute?
[whatwg] The placeholder attribute
The semantics of the placeholder and title attributes of inputs overlap slightly; the placeholder attribute may contain a hint to aid the user, while title is to contain other advisory text. I can think of two valid uses of placeholder: example value, and the text click here to type or enter search query here. The latter is obviously user interface that should be implemented by interactive user agents. Then there is the third use, use it as a title attribute (but with richer presentation). Users might want values falling under the first to be prefixed with e.g., for example or equivalent - but by allowing the latter use forces authors to add it to all example values, rather than letting the user's style sheet take care of it. Thus I suggest narrowing the semantics of the attribute to example values, allowing for easier styling by users (or agents, on their behalf). The second one should have no valid representation. Lastly, the specification should make it clearer what the title attribute is appropriate for; a description of the input or format. Also, I see no reason to suggest not rendering the text when the input is focused - in special on 1D devices such as speech - considering that JavaScript dependent sites (such as Hotmail) have placed example values in a small font below the input so that it can be visible while the user is typing, and, more importantly, after the input has been focused (whether automatically or manually), but before the user starts typing. As for the argument against using the title attribute for everything that it would break existing sites, I do believe rendering the title attribute of an empty and unfocused input inside of it is an improvement over displaying a tooltip a second or two after the user positions a cursor over the input (irrespective of focus). How on Earth is anyone to think of doing that? Displaying the title attribute in a floating box in a margin when an input is focused, followed by the example value prefixed with e.g. would be my preferred rendering, but that's just my opinion. P.S. The last paragraph of the section on the pattern attribute links twice to semantics.html#the-title-element. Should it not link to elements.html#the-title-attribute?
Re: [whatwg] Proposal for improved handling of '#' inside of data URIs
Þann sun 11.sep 2011 18:44, skrifaði Michael A. Puls II: I don't think and are in the list of safe URI characters. All URI-based functions seem to percent-encode them too. Keeping them encoded is definitely good for data URIs in text/plain documents so the don't interfere with the and that encase the URI. You are right, they are delims and MUST be percent encoded.
Re: [whatwg] comment element
Þann fös 9.sep 2011 19:27, skrifaði Benjamin Hawkes-Lewis: On Thu, Sep 8, 2011 at 4:58 PM, Bjartur Thorlaciussvartma...@gmail.com wrote: Why usea when you have onclick and a settable document.location? :) I think there are sound reasons to provide user agent conformance requirements for a@href and to allow it as conforming markup that go well beyond semantics for semantics sake, including: 1. Links are the essence of the web, so if you're going to express *any* semantic in a web markup language, you should express links. True dat. 2. a@href is very common in the web corpus, therefore user agents must implement a@href to provide access to the existing web corpus. True for anchors, but irrelevant in a discussion about the introduction of a new element (or more correctly; new semantics for an element). 3. Making a@href non-conforming would _not_ help authors make their pages more interoperable. 4. We do not want to make navigating the web dependent on executing third-party script, since some user agents do not implement scripting and some users may disable script for usability or security reasons. Nor should we depend on site stylesheets for rendering documents beautifully. 5. a@href is a significantly easier to author than any form of scripted link. This probably being the original reason (simplicity, that is, not being easily typeable by authors). 6. a@href has built-in accessibility (e.g. keyboard activation, lists of links in screenreaders, etc.). Yes, although I believe lists of links to be generally useful, even in pixmap renderings (as a suggestion list for navigation). 7. Semantic markup is deterministic in a way that arbitrary script is not. Being able to infer relationships between documents without executing script makes it much easier for automated agents to make use of those relationships. For example, Google PageRank delivers extremely good search results by analysing links expressed through this simple semantic markup. This. May I reemphasize again. However genius, Tim Berners-Lee did most likely not foresee the use case of building a database of links between documents. Simply butting the information out there, seemingly when essaying to make documents output medium independent, made creative analysis of a enormous amount of existing and future to be machine interpret. Machine readability is a great reason for semantics, even if seemingly for semantics sake.
Re: [whatwg] Proposal for improved handling of '#' inside of data URIs
Þann lau 10.sep 2011 21:15, skrifaði Daniel Holbert: * Opera is interesting -- it can exhibit either the Firefox or WebKit behaviors in tests A/B/C, depending on whether the data URI as an embedded element (via iframe/img) or view it directly. When you view it as an embedded element (in my testcase), Opera matches WebKit on A/B/C (including the XML parse error on C). However, if you *directly view* the data URIs (right-click on iframe, Frame|Open, focus URLbar hit enter), then Opera matches Firefox. Also, Opera passes test D. So Opera treats the src attribute as a URI, but the href attribute and identifiers input by users as URI references? This does not conform to the WHATWG HTML5 standard that uses delegates the definition of URI to RFC 3986 which again defines the # character as a beginning a fragment identifier, and not quite to RFC 2396, delegated to by HTML 4.01 which forbids #s in URIs, but uses it as a separator between URIs and URI references (but doesn't specify how to parse URIs who are not part of URI references). I believe the HTML 4.01 usage of the term URI instead of URI reference to be an error, but the HTML working group has to confirm that (or editor(s) on it's behalf). According to my interpretation of RFC 2396 the # should terminate the URI, as URI can't contain #, but this isn't stated explicitly and thus I can't tell if Opera violates the RFC or not, and thus not if it's correct or not. It's clearly violating RFC 3986, however. The correct thing to do seems to be to to violate HTML 4.01 RFC 2396 but conform to HTML5 RFC 3986. Adding a special case for one URI scheme seems a little odd, but I can't think of a use case for fragment identifiers in data URI.
Re: [whatwg] [editing] New conformance tests
Þann mið 7.sep 2011 20:44, skrifaði Aryeh Gregor: I've had some type of tests around for a while now, but they weren't suitable for implementers. I've now recoded and reformatted them so that they output a table of results using James Graham's testharness.js. The link is here, but WARNING: it will run script continuously for a few minutes, which will freeze Firefox (Chrome is fine): http://aryeh.name/spec/editing/conformancetest/runtest.html I haven't tested it yet in IE or Opera, but obviously that's fairly high on my priority list. I also intend to break it up into more manageable chunks so it doesn't freeze the tab or browser for quite so long. The tests are documented in the specification itself: It freezes surf as well, and then crashes it (though that's clearly a bug in surf and maybe JavaScriptCore). Opera runs it fine, but the chrome is slowed down severely. The results are quite a bit bigger than my copy buffer, and polite ML messages, though :) Maybe my Opera build is just plain outdated, but I felt the numbers might be interesting either way. Opera 10.60 Internal. Build 6386 for Linux. Compiled on Jun 30 2010 by gcc 4.3.2 (ABI: 1002) for GNU libc 2.7. Time elapsed: 2:38.857 min. Summary Found 56720 tests 13685 Pass 43035 Fail
Re: [whatwg] comment element
A far greater problem is the lack of standardization of a protocol for comment submittal. If the IETF were to standardize such a protocol, would it not make more sense to distribute comments via the same channel? That seems like a cleaner long-term solution than changing every stream format out there to enable in-band comment transfer. Classes are a good enough interim solution. Þann þri 6.sep 2011 19:28, skrifaði Benjamin Hawkes-Lewis: On Tue, Sep 6, 2011 at 8:02 PM, Jukka K. Korpelajkorp...@cs.tut.fi wrote: Self-containedness is relative. But this does not mean it is empty concept. And if it were, why use it at all? Surely there is a difference between, say, a blog entry or a newspaper article carefully crafted to stand on its own, so that you can read it as such and take a position on it, and a typical blog comment or a comment in an online news system where nobody expects your comments to be in any way understandable outside the context. One can draw all sorts of distinctions; not all of them need to be expressed in markup. From the definition of the article element: The article element represents a self-contained composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication. By your logic that everything should be considered self-contained, as nothing is truly self-contained, anything could be marked up with the article element, rendering the element meaningless. Such arguments could be used against _any_ new markup elements (and almost any existing elements - do we really need much more elements thana when we can use metadata, styling, and scripting? :-)). Why use a when you have onclick and a settable document.location? :)
Re: [whatwg] add html-attribute for responsive images
Bottom (top?) line: User agents should negotiate an appropriate
message-body size using HTTP. Sending an accept-size (or some such)
could solve both the problem of high resolution photography and lengthy
documents. The amount of split articles (Click here to go to the next
page / page 4) and long search results show clear demand.
Þann mið 31.ágú 2011 21:32, skrifaði Karl Dubost:
Anselm,
(setting reply-to on www-style)
Seen this today, to remind people that it is not just
something up in the air. People need it.
http://www.webmonkey.com/2011/08/speed-up-your-responsive-designs-with-adaptive-images/
I wonder if it could be handled by CSS in fact.
Different technologies seem appropriate depending on the relation
between the document and the images.
Use Case A
Multiple representations of a resource may exist, where all can be
deduced from the original (e.g. by downsampling). Doing the deducing on
the server is an optimization to save bandwidth.
Proposed Solutions
1) Nest objects
2) Negotiate content serverside as per HTTP
3) Negotiate content clientside as per HTTP
Use Case B
An article might link to (directly or, theoretically, via a
text/uri-list) to a number of non-critical asides (i.e. images to rest
your eyes on, background music, etc), that may be omitted, but are in no
way the same resource.
Proposed Solutions
1) Use links or as with an appropriate relation specified
2) Use your favorite linking element (be it a, area, object, img, audio,
video, link, a future media element not yet specified, or an old one not
yet deprecated) in an aside.
3) Add the rel attribute to object, and use instead of a in 1. See A.1
Expected Rendering
User agents are to render zero or more of the tolinked resources,
omitting none, some or all of the resources completely from the output
viewport, or rendered only on demand.
I guess Anselm, you could ask there.
On the www-style mailing-list, Charles proposed [1]
content: url(img.jpg) replaced;
I'm not sure I fully understand the proposal
but we can imagine something that could fit nicely
with the CSS Generated Content Module Level 3 [2]
img class=responsive src=http://example.org/foo; alt=wiizz/
and then the CSS
@media screen and (min-width:550px) and (max-width:960px) {
img.responsive {
url(http://example.org/foobis) replaced;}
}
@media screen and (min-width:240px) and (max-width:549px) {
img.responsive {
url(http://example.org/footer) replaced;}
}
And allocate every image a class, and every sample a rule in a style
sheet? Maybe, if the images are decorative, but I think you can come up
with a more clever solution using media fragments (either standardized,
or implemented per site by binding media queries to URI templates).
Re: [whatwg] [editing] Additional miscellaneous commands
Þann mán 22.ágú 2011 21:57, skrifaði Ehsan Akhgari: On 11-08-18 6:09 PM, Bjartur Thorlacius wrote: That seems to be of general utility. I recommend sending feature request to implementors. I think a much shorter path to success would be having a Show/Hide All Comments button. :-) Yeah, by all means, reword the button's label. But there are other (minor) use cases for searching for hidden text: hidden sections (such as in scripted pages that present only one section at time) developed by people outside of the WHATWG. But maybe having invisible elements appearing upon search is just plain confusing?
Re: [whatwg] [editing] Additional miscellaneous commands
Þann fim 18.ágú 2011 21:05, skrifaði Alfonso Martínez de Lizarrondo: Now if someone had some bright idea to enable finding in the hidden text that would be perfect, but the view source workaround is good enough for the moment. That seems to be of general utility. I recommend sending feature request to implementors. That's just CSS and I'm not sure if it should be present in this spec, but on the other side it's clear that besides the .execCommand a good Editing spec should state or hint about other features that the browsers must implement to behave properly (like showing the caret so the user knows where he's typing, enable the user to select parts of the content,...). These might look trivial, but iOS5 seems to be the first mobile browser that will behave good enough so that both CKEditor and TinyMCE will enable the support for it (check the comments in http://code.google.com/p/android/issues/detail?id=8253 about the Android browser) As long as overspecification is avoided (care must be taken to allow e.g. caret(s) to be hidden when another top-level window is focused, etc). A browser that provides a perfect implementation of all the execCommands but doesn't allow the user to type or select is worthless for editing. Then requiring implementations to allow users to select and replace any substring consisting of a sequence of whole characters (i.e. characters represented by a single glyph) and insert text of their own at any character boundaries seems reasonable. I don't see why mandating carets is needed. Should users not be allowed to edit editable content using structural and/or aural editors?
Re: [whatwg] video preload implementation feedback
Þann mið 17.ágú 2011 15:44, skrifaði Philip Jägenstedt: I'd very much like to see feedback from other implementors. Are you happy with treating autoplay and preload as just hints as in [4] or do you think that we should specify them in greater detail? (This does not preclude having user preferences to override the standardized defaults.) If an UA may ignore them, than them being honored can't be relied upon - rendering the default configuration a question of implementation (i.e. providing sane defaults for the user agent's target user base) but not of interoperability.
Re: [whatwg] sic element
Þann fim 11. ágúst 2011 04:54, skrifaði Jukka K. Korpela: It's debatable and irrelevant in this context what RTF, TeX, and text/enriched are. The issue is whether HTML can express simple things like bolding in quoted material - or, rather, whether such simple expressivity is to be declared obsolete and an error (even though browsers are required to support it). My take on it is that implementations should interpret typographic elements literally if descendants of q or blockquote, but as optionally offset spans otherwise (i.e. optionally spoken in an alternative mood, or rendered in an alternative font), using the intended font or style wherever practical. The fact that speech renderings preserve neither bolding nor italicization implies that implementors have not interpreted b and i to mean bold and italics, respectively, but as hints as to appropriate visual renderings Speech renderings cannot present bolding and italics at all, so the argument does not stand. It's not a matter of being hints versus essential markup but a matter of limitations of the medium. The debate is about whether an expected speech rendering of e.g. bsome text/b would be some text or [brief pause] bold [brief pause] some text [brief pause] end bold. The former rendering is lossy, and if the bold font is in fact required, the latter rendering makes sense. The only use case I can come up with where the latter rendering would actually be useful is discussion of the typography of a printed document. That would clearly not be a great enough use case for introducing new elements to the standard, and only considered as the elements are widely implemented already. that happen to map quite reliably to aural renderings No they don't, and speech renderings do not work consistently, even though some of them may, at least with some settings on, let b and i affect the rendering somehow. Bolding and italics are traditional devices of print typography, with multiple uses, and many of those uses (like italics for foreign words) do not involve any emphasis that should be expressed in speech. The question is what *should* a user agent do with typographical elements when the appropriate font is unavailable? A) Set it off from the surrounding text by other means, or ignore it B) Convey the style by other means (such as by prefixing it with the font style name) C) Ignore it Ian's draft specifies A. I'd be (not quite) content with B in quotes and A otherwise. Are you arguing for C? This is not about stretching anything. The B and I elements were introduced at the same time as STRONG and EM, so they were clearly meant to have a different meaning, namely indication of physical presentation. Yes, and more importantly the historical draft explicitly states that B and I are only to be bold and italic where practical, and that alternative mappings are allowed. Hence my interpretation: the appropriate font and style where practical, an alternative otherwise. The historical draft http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt says this clearly, and it says: Some of these styles are more explicit than others about how they should be physically represented. The logical styles should be used wherever possible, unless for example it is necessary to refer to the formatting in the text. (Eg, The italic parts are mandatory.) It does not sound good to tell authors to move away from HTML to a completely different data format just because there is a need to express bolding. And regarding new markup languages, well, they can be designed if desired, but we would need to allow several years for delivery, and while waiting for that, can we just keep using the well-defined classical tags, please? HTML-compatible != completely different data format. I meant to suggest using a subset of HTML with a new doctype, understood by existing HTML implementations, to instruct non-visual user agents to preserve the boldface and italics even in non-visual renderings. A processing instruction or attribute would achieve the same. I still don't understand how you want non-visual UAs to render typographical elements.
Re: [whatwg] File API Streaming Blobs
Þann mán 8.ágú 2011 20:31, skrifaði Simon Heckmann: Well, not directly an answer to your question, but the use case I had in mind is the following: A large encrypted video (e.g. HD movie with 2GB) file is stored using the File API, I then want to decrypt this file and start playing with only a minor delay. I do not want to decrypt the entire file before it can be viewed. As long as such as use case gets covered I am fine with everything. Has the decryption to happen above the File API?
Re: [whatwg] sic element
On Sun, Aug 7, 2011 at 5:42 AM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: Bjartur Thorlacius wrote: [...] Please note that this isn't about favoring HTML over presentational markup languages; none of the alternatives mentioned is a markup language at all. RTF, TeX and text/enriched are. Consider them before choosing HTML. HTML has always been a presentational markup language, too, and HTML as officially defined (HTML 4.01, XHTML 1.0) still has presentational features, so the question is whether they should be taken away, not about redefining them. It is the WHATWG HTML5 work that is proposing a redefinition. (I say proposing, since from the viewpoint of implementor, author, and user communities as well as the W3C, they are proposals, not a standard. In many parts of HTML, the proposal has widely been or is being accepted in practice, but I see little signs of such things happening with the new meanings for b and friends.) And perhaps blockquote standardized to mean indent. I wouldn't object to that, but _that_ would mean a change to the tradition of HTML specifications, and although blockquote mostly means indent, it fairly often means a block quotation. Moreover, the situations where an HTML author needs to say this text is indented in the printed original without presenting any fixed interpretation of the intended meaning of indentation appear to be rather rare, as compared with situations where one needs to say e.g. this text appears in italics in the printed original. If you simply retype print without any interpretation of the typography used, a valid speech rendering would e.g. cue bold text with bold and unbold marks to convey the meaning: this text was bold. It could, and that would actually reflect the authors intentions: he wishes to convey the idea of bolding, leaving it to the reader to infer or guess the meaning of bolding. (At the extreme, you might have a page that discusses a printed document in general and the use of bolding in it in particular, and then it is surely relevant to indicate the bolding - as pure bolding.) In practice, speech rendering doesn't behave that way, but even if it did, it would constitute an argument in favor of the typographic markup, not against it. The fact that speech renderings preserve neither bolding nor italicization implies that implementors have not interpreted b and i to mean bold and italics, respectively, but as hints as to appropriate visual renderings - that happen to map quite reliably to aural renderings[1]. In other words: b and i are there for WYSIWYG composers and editors. If formatting is semantically critical, use one of OpenDocument, TeX, RTF or text/enriched. This isn't about suggesting, this is about reproducing aspects of printed material that may be essential. It is comparable to making a distinction between lowercase and uppercase, which may be purely presentational or may carry essential information. The case distinction can be made by the simple choice of letters at the character level, or it may be delegated to CSS if it is regarded as purely presentational. For bolding etc., the character-level alternative does not exist or it is highly impractical (and e.g. mathematical italics letters are, in addition to being present in a few fonts only, intended for mathematical use rather than common use of italics). So all I'm asking is to preserve the existing features of HTML or, more exactly, preserve them without declaring them as obsolete. HTML was not designed for this, but could arguably be stretched to fulfill the use case, considering existing visual implementations. A method to declare that the typographical elements do not convey the same semantics as their respective fonts, but the fact that the enclosed text was typeset using the respective font. The preferred solution would be a new HTML-compatible markup language (say, a structural and presentational subset mandating a new doctype), or one of the existing typeset file formats. [font as in style, not typeface] 1: From Wiktionary's definition of empasis: Prominence given to a syllable or words, by raising the voice or printing in italic or underlined type.
Re: [whatwg] Small consistency issue with HTML5 nav element examples
On 8/2/11, Ian Hickson i...@hixie.ch wrote: Unfortunately, as I said above... what we want and what we get don't always match. There's not much we can do here to push authors further. On the other hand, why accommodate the desires of authors? Why let authors decide whether I use gold on black or black on white? But I guess my concern is mainly an implementation issue at this point, as authors have assumed complete control over the rendering of their documents.
Re: [whatwg] sic element
Þann þri 2.ágú 2011 09:04, skrifaði Henri Sivonen: On Fri, 2011-07-29 at 22:39 +, Ian Hickson wrote: Presentational markup may convey useful information, for example that a quotation from printed matter contains an underlined word. HTML is the wrong language for this kind of thing. I disagree. From time to time, people want to take printed matter an publish it on the Web. In practice, the formats available are PDF and HTML. HTML works more nicely in browsers and for practical purposes works generally better when the person taking printed matter to the Web decides that the exact line breaks and the exact font aren't of importance. They may still consider it of importance to preserve bold, italic and underline and maybe even delegate that preservation to OCR software that has no clue about semantics. (Yes, bold, italic and underline are qualitatively different from line breaks and the exact font even if you could broadly categorize them all as presentational matters.) I think it's not useful for the Web for you to decree that HTML is the wrong language for this kind of thing. There's really no opportunity to launch a new format precisely for that use case. Furthermore, in practice, HTML already works fine for this kind of thing. The technical solution is there already. You just decree it wrong as a matter of principle. When introducing new Web formats is prohibitively hard and expensive, I think it doesn't make sense to take the position that something that already works is the wrong language. So you're arguing that a subset of HTML should be favored over presentational markup languages for marking up digital retypes of printed matter, with b, i, u, font, small and big be redefined to their HTML 3 typographical meanings. And perhaps blockquote standardized to mean indent. If you simply retype print without any interpretation of the typography used, a valid speech rendering would e.g. cue bold text with bold and unbold marks to convey the meaning: this text was bold. The current definition of b does not exactly hint at such renderings. If all you want is to suggest original typographic rendering, then (save for Excerpt/Blockquote, Nofill/Pre and Lang/@lang) CSS does the job, better - and is vastly more powerful. I think the reason why Jukka and others seem to be confused about your goals is that your goals here are literally incredible from the point of view of other people. Even though you've told me f2f what you believe and I want to trust that you are sincere in your belief, I still have a really hard time believing that you believe what you say you believe about the definitions ofb,i andu. When after discussing this with you f2f, I still find your position incredible, I think it's not at all strange if other people when reading the spec text interpret your goals inaccurately because your goals don't seem like plausible goals to them. If if the word presentational carries too much negative baggage, I suggest definingb,i andu as typographic elements on visual media (and distinctive elements on other media) and adjusting the rhetoric that HTML is a semantic markup language to HTML being a mildly semantic markup language that also has common phrase-level typographic features. The problem is that the facts that something was written underlined, spoken with a stress and that styles guides recommend underlining the text when printed to convey it's semantics are not all equal. They might all be conveyed in print by underlining the text, but the semantics differ and thus each needs an element of it's own. Much as authors must use ol, ul and blockquote to convey their defined meanings, even though some UAs might render all of them the same way.
Re: [whatwg] input type=password... restrict reading value from JS?
Þann mán 1.ágú 2011 15:25, skrifaði Aryeh Gregor: If you're doing useful password strength checks, regular expressions won't cut it. For instance, you'll want to check against dictionaries. Regex is only useful for crude and ineffective checks like must be at least six characters long with mixed-case letters, numbers, and punctuation (= Abcd0! is okay, effervescentarcheopteryxattack is not). My point is that a sites aren't going to distribute JavaScripts that fetch a cracklib dictionary and look the password up in it. A cracklib may be available to the user agent, in which case the UA can look the typed in password up. Unfortunately, the UA probably won't know if the password is input for registration or login, but that can be worked around with Don't warn me again buttons on the passive warnings. And even if you want to allow authors to recommend dictionaries, doing so on as high level as possible (i.e. declaratively) simplifies caching, especially important where a cache miss will be an exception. JavaScript acts as the agent of the receiving server. This is a cornerstone of the web security model. The server is what sent you the JavaScript, so it's trusted to act on behalf of the site. There's no way you're going to paper this over by trying to remove one or two minor privileges from JavaScript. (Yes, there are a few cases where we do this as an XSS defense-in-depth measure, like HttpOnly cookies, but only for very narrow things where it makes sense.) Indeed. This is one of the reasons some people disable JavaScript. Most don't, as they don't want to stop JavaScripts from doing other more useful things. If we disable just stuff like this we can bring some security to the folks that have JavaScript enabled (such as me). No you can't. JavaScript can replace arbitrary page content. You can't work around that without crippling it. As I suspected. Are XHR submits of passwords common and important enough to outweigh the security cost of scripts having access to all passwords in their document(s)? Yes. We can't stop them without breaking the web. I propose disallowing changing the action attribute of forms with password inputs. We can't do that without breaking the web. There are going to be countless sites that rely on being able to create forms in JavaScript, which includes setting their action attribute and includes forms with password inputs. Ok. I'll use HTTP authentication methods or HTML login forms in a dedicated document (linked to with sandboxing where applicable).
Re: [whatwg] input element list attribute and filtering suggestions
Þann mán 1.ágú 2011 15:28, skrifaði Aryeh Gregor: On Fri, Jul 29, 2011 at 7:24 PM, Ian Hicksoni...@hixie.ch wrote: The overarching counterpoint is that in-page UI *is* an authoring issue, because authors want to control exactly how their page looks and behaves. Browser/chrome UI issues shouldn't be standardized, but page UI issues absolutely should (at least in many cases). Every imaginable output media, or just the most common one?
Re: [whatwg] input element list attribute and filtering suggestions
Þann mán 1.ágú 2011 15:28, skrifaði Aryeh Gregor: On Fri, Jul 29, 2011 at 7:24 PM, Ian Hicksoni...@hixie.ch wrote: The overarching counterpoint is that in-page UI *is* an authoring issue, because authors want to control exactly how their page looks and behaves. Browser/chrome UI issues shouldn't be standardized, but page UI issues absolutely should (at least in many cases). Every imaginable output media, or just the most common one?
Re: [whatwg] input type=password... restrict reading value from JS?
On 7/11/11, Sean Connelly s...@pbwhere.com wrote: As a web developer, if I wanted access to the password, I would then avoid using the input type=password field, and create my own field that reads characters (perhaps via onkeyup), and fakes a password field visually. Fair point. I also worry about attackers removing a form and inserting their own, or even positioning their own over the old one - if they manage to gather enough information about the victim's UA or if the form of a password input is consistently positioned. I also think it's a bad idea to change the behavior of input type=password because it will break websites that assumed they could read the value. Perhaps a website checks against a user's past 10 passwords to see if they are using the same one, via XHR. Or perhaps the entire login process is XHR. Who knows. So there are two use cases for reading user passwords: * client side password strength indicators ** telling users if their passwords conform to site specific password restrictions - arguably bad practice - IMO better achieved with declared regular expressions ** generally informing users of the computing needed to brute force their password open, and if it's in a dictionary -- fetching a dictionary from each site is impractical (and thus only implementable by UAs) -- can be implemented by UAs without braking sites that work if laid out in the same way as the author's UA with floating overlays that appear only while the password input is focused and has input * XHR submit - Could forms be targeted to a new browsing context and the server return a HTTP 204 response instead? - Are implementors willing to display a more prominent notice of the status of the submit (e.g. the text Submitting under a spin-wheel, and then the Reason-Phrase of the request colored or on a background colored to convey the status code)? I think there is definite room for improvements in security when it comes to input type=password, and I've also been trying to make it more secure by designing some sort of client-side hashing. But I don't think restricting JavaScript from reading the value is a security benefit... in my opinion, it would just be a hassle for developers who need to read the value, and force them to use another means of password entry where they can read the value. I don't think anyone but the receiving server should be able to read my password. This is one of the reasons some people disable JavaScript. Most don't, as they don't want to stop JavaScripts from doing other more useful things. If we disable just stuff like this we can bring some security to the folks that have JavaScript enabled (such as me). On Sun, Jul 10, 2011 at 4:38 PM, Aryeh Gregor simetrical+...@gmail.comwrote: On Sun, Jul 10, 2011 at 4:08 AM, Alex Vincent ajvinc...@gmail.com wrote: with a XHR I can send that password somewhere it shouldn't go... (well, with cross-domain security code, maybe not, but that's not the point.) Are XHR submits of passwords common and important enough to outweigh the security cost of scripts having access to all passwords in their document(s)? You can send it anyway by changing the action attribute on the form and calling submit(). So what attack scenario are you actually avoiding here? You'd need a really strong security benefit for it to be possible to even contemplate breaking so many websites. I propose disallowing changing the action attribute of forms with password inputs. That is, if we manage to squash all the other obvious ways a script can compromise the security of a typed password. This seems to involve a lot of tedious allowance of this and that to be done to forms, except if you throw in a password input. I'm not to judge if it's worth it.
Re: [whatwg] Page displayed during/after download (meta refresh downloads)
Þann fös 22.júl 2011 23:09, skrifaði Kornel Lesiński: 2. Allow website to show additional information about the download, while the download is taking place. And to satisfy all three cases (without breaking links), it needs to be done at HTTP level, by adding HTTP header (or multipart response? or attribute to Content-Disposition?) that causes both file download to start and a page to be displayed at the same time. Sending multiple responses in reply to a single request is generally useful, but seems hard to implement in a fashion compatible with HTTP pipelining clients. How about a JavaScript opening a new browsing context and navigating it to the additional metainformation when the user follows the link?
[whatwg] window.status and window.defaultStatus
Are JavaScript implementors willing to reimplement window.status? There are obvious security problems with drawing an author-provided string where a certain URI is expected, but could window.defaultStatus not set the name (_NET_WM_NAME or equivalent) of the script's window and window.status either override window.defaultStatus temporarily, or sent to the user, e.g. through Growl or as a Windows toast. The window name is already accessible to scripts (by modifying the text child of title through the DOM) so no new security concerns are introduced. The Growl binding might well be better by a new function, though.
Re: [whatwg] a rel=attachment
Þann fös 15.júl 2011 18:39, skrifaði Jonas Sicking: 2011/7/14 Ian Fette (イアンフェッティ)ife...@google.com: One concern which was brought up was the ability to cause the user to download a file from a third party site. I.e. this would allow evil.com to trick the user into downloading an email from the users webmail, or download a page from their bank which contains all their banking information. It might be easier to then trick the user into re-uploading the saved file to evil.com since from a user's perspective, it looked like the file came from evil.com Would it not be possible to send an unauthenticated request for the file, if it's of different origin?
Re: [whatwg] a rel=attachment
Þann fös 15.júl 2011 21:34, skrifaði Darin Fisher: 2) Unlike rel=something, @download provides a way to specify the name of the file to save. This makes the feature useful with data: URLs and blob: URLs (that are not backed by a single file). This is valuable to me because I can imagine wanting to save the contents of acanvas, and that probably involves saving the data URL that you get from toDataURL(). 3) The target=_download idea is interesting, but I'm not sure we can safely introduce new target values, and this also suffers from not providing a way to specify the downloaded filename. Is there any other use case for providing the filename than using canvas' toDataURL instead of blobs (a use case more simply served by FileSaver)?
Re: [whatwg] The blockquote element spec vs common quoting practices
Þann sun 17.júl 2011 18:36, skrifaði Jukka K. Korpela: 17.07.2011 18:07, Nils Dagsson Moskopp wrote: I think it would be rather trivial. The string “ISBN” followed by something that matches the syntax of ISBN numbers, perhaps allowing some variation in punctuation, could be treated as an implicit link to a resource _if_ you have some mechanism(s) for mapping ISBN numbers to URLs. The key issue is whether browser vendors have interest in it and which mechanism(s) would be used. After all, an ISBN could be in a multitude of ways, like querying an online bookshop, querying an online bibliographic system, or querying an site of books in digital format online. Which one should be used? Would it be useful? To be really useful, it should be handled so that the browser checks what it can get using the ISBN and then make that information available to user (how to get bibliographic info, how to read reviews, how to buy the book, how to borrow it in a library, download or read the book via the net for free or for fee). I don’t think it’s much used in the wild, except on pages by organizations that define HTML specs. What might be the motivation for browsers to do something special with it? Surely you could make things so that by clicking on a blockquote, the user accesses the resource pointed to by the cite attribute. Browsers could do that, and so could authors. But would users actually start clicking on quotations to see their sources? Surely they would far more probably click on the title of a work in visible credits if present and if it is a link, so what would the cite attribute help? Good point No, it’s not a category thing. It’s about the relativity of being “machine-readable.” You are probably thinking of data in a specific format designed to be easily parseable and useable by computer software, such as a URL, an ISO 8601 date notation, or an XML tag. But browsers already do many kinds of heuristics, parsing data that doesn’t really match the specs. You *could* interpret handwritten text on a piece of paper using a machine and parse it as HTML. I'm not volunteering for making a machine for that task. A title of a work is easily useable by software: put it inside quotation marks and throw it at Google, and the odds are that you get some useful links related to it, if there’s info on the work (and perhaps the work itself) on the web at all. Well, assuming that the title is relatively unique. Titles of works are often more useful in the long run than URLs. URLs change far too often when sites are revamped or for other reasons. ISBNs are more useful in the long run than titles. Good titles get reused far too often. I think a good start would be to add an optional (but usually recommended) credits or source element for use inside blockquote. What about the common case of multiple quotations credited to the same source (interleaved with comments).
Re: [whatwg] Custom protocol handlers
Þann sun 17.júl 2011 22:46, skrifaði Ben Schwarz: 3) As a web designer / developer I want to be able to ascertain if another website has registered a custom protocol handler in the user’s browser So that I can knowingly design and implement an integration experience 4) As a web designer / developer I want to be able to ascertain whether the user has installed a custom protocol handler within their operating system So that I can knowingly design and implement an integration experience Your requirements seem reasonable at first glance, but it's hard to tell if and how to give this information without a concrete example of how it is going to be used. How is designing and implementing an integration experience possible with the information that a competitor has registered a protocol handler?
Re: [whatwg] The blockquote element spec vs common quoting practices
On 7/15/11, Jukka K. Korpela jkorp...@cs.tut.fi wrote: 14.07.2011 16:10, Bjartur Thorlacius wrote: I don't think author names are allowed in cite in HTML 5. They aren’t, but HTML5 linters (“validators”) won’t report the issue, as they don’t understand the meanings of words. That doesn't make it any more valid.
Re: [whatwg] The blockquote element spec vs common quoting practices
On 7/15/11, Jukka K. Korpela jkorp...@cs.tut.fi wrote: Should it? Even when the book has no URL? If you expect urn:isbn:… to work anytime soon in any significant browser, you’re very optimistic. Wikipedia and Amazon (among others) have all the mechanisms already. Such ISBN handlers could even be registered by JavaScripts. Browsers currently treat cite just like i (except that it has a different name). There is no sign of advance functionality emerging. It does not matter how usable something is when it does not exist at all. Cite is not nearly as useful as @cite. I forgot to mention that the ISBN number should be included visibly in the credits, especially because it is usually the simplest and sometimes the only reasonable way to identify a book unambiguously (and can be copied and pasted into a suitable bibliographic search form). It’s So you're saying that users should rather search for the term ISBN, select the following number, copy it, remove/add hyphens as necessary and then paste it to a suitable bibliographic search form? Instead of registering a suitable bibliographic search form once, and having the user agent do the hard work in a click or two? metadata, but metadata that need not and should not be hidden but presented in textual content. At most it might be included into elements that are not initially displayed but become available when the user so requests—possibly some day via the details element if browsers implement it well. But browsers need to be told that that number close to the quotation is an ISBN. And if you always hide it in details, user agents may be compelled to expand it by default, making it unusable for e.g. hiding answers to a quiz. The cite attribute in blockquote should really be moved to the non-recommended part of HTML. It hardly ever serves a useful purpose, and it tends to mislead authors into including important information _only_ in the attribute, which has no browser support worth mentioning (despite having been in HTML for over 13 years). Before you said cite was implemented as i, and your point is that the cite attribute is useless? They're barely related, @cite contains an URI, that an user agent might be able to use in an automated fashion. Cite contains a human-readable name of a work. That'll rarely be machine-readable.
Re: [whatwg] The blockquote element spec vs common quoting practices
Þann fim 14.júl 2011 09:38, skrifaði Oli Studholme: in graphic design a footer contains supplementary information about the content it follows. the spec initially disallowed ‘fat footers’, but the naming and common usage would have led to people using them for fat footers regardless of the spec. they still contain supplementary information about their sectioning element or sectioning root. This semantic connection seems stronger to me than one based on arbitrary size Would it not be less confusing to forbid 'fat footers' and rename footer - credit?
Re: [whatwg] The blockquote element spec vs common quoting practices
Þann fim 14.júl 2011 11:09, skrifaði Jukka K. Korpela: 14.07.2011 13:49, Karl Dubost wrote: blockquote cite=urn:isbn:978-2-07-07533-7 pSur un pétale de lotus, j'écrivis ces quelques vers :/p p«qMême si l'on vient me chercherbr/ Comment, abandonnant la roséebr/ De pareil lotus,br/ Retournerai-jebr/ Dans le monde changeant et frivole ?/q »/p pet j'envoyais ce pétale./p p class=source cite class=auteurShonagon, Sei/cite, cite class=titreNotes de chevet/cite, p.64, Unesco, NRF, 1966./p /blockquote Yes, but for usability reasons the cite[@class=titre] should represent a hyperlink to the cited book. Is an user agent to find a cite descendant of blockquote and make it represent a hyperlink to the cited resource (identified by the URI in the cite attribute of blockquote)? (I don't like to nitpick on the author identification, but wouldn’t cite class=auteur lang=jp-LatnShōnagon, Sei/cite be better?) I don't think author names are allowed in cite in HTML 5.
Re: [whatwg] The blockquote element spec vs common quoting practices
On 7/14/11, Kevin Marks kevinma...@gmail.com wrote: There is another common pattern, seen in blogging a lot, of putting the citation at the top eg As cite class=vcarda href=http://www.gyford.com/phil/; class=url rel=acquaintance met colleagueabbr title=Phil Gyford class=fnPhil/abbr/a/cite wrote about the a href=http://www.gyford.com/phil/writing/2009/04/28/geocities.php;ugly and neglected fragments/a of Geocities:/p blockquote pGeoCities is an awful, ugly, decrepit mess. And this is why it will be sorely missed. It’s not only a fine example of the amateur web vernacular but much of it is an increasingly rare example of a emperiod/em web vernacular. GeoCities sites show what normal, non-designer, people will create if given the tools available around the turn of the millennium./p /blockquote (from jeremy) or pretty much any post here: http://www.theatlantic.com/ta-nehisi-coates/ Would a header pattern in the blockquote work for this? If I was writing a detector for this pattern, a followed by a colon and blockquote would do it pretty reliably... Ideally, the same markup should be used to mark citations up whether they're displayed one way or another. Whether to render author name(s) before or after the quotation is a matter of style.
Re: [whatwg] a rel=attachment
On 7/14/11, Ian Fette (イアンフェッティ) ife...@google.com wrote: Many websites wish to offer a file for download, even though it could potentially be viewed inline (take images, PDFs, or word documents as an example). Traditionally the only way to achieve this is to set a content-disposition header. *However, sometimes it is not possible for the page author to have control over the response headers sent by the server.*(A related example is offline apps, which may wish to provide the user with a way to download a file stored locally using the filesystem API but again can't set any headers.) It would be nice to provide the page author with a client side mechanism to trigger a download. As already stated you can use rel=enclosure. Alternatively, you can specify the type attribute with the appropriate value and let the user agent offer to write it to permanent storage.
Re: [whatwg] a rel=attachment
On 7/14/11, Karl Dubost ka...@opera.com wrote: what about adding a href=foo.pdf target=_downloadSave a Tree, Eat a beaver/a This seems like the best solution to me. A filename hint has two use cases: a suggestion for a local identifier, and providing a filename extension for systems that use them to identify file types with incomplete or nonexistent /etc/mime.type media type mappings. I'll only name so many pictures pic.jpg, so I suggest using the descriptive (and thus verbose) value of the title attribute. The worst problem will be encoding the name on filesystems such as FAT. a href=//samplecdn.example/pix/2011/7/14/party/cake title=Súkkulaðikaka með ís target=_downloadAfmæliskaka mín/a
Re: [whatwg] The blockquote element spec vs common quoting practices
Þann þri 12.júl 2011 09:15, skrifaði Oli Studholme: Firstly thank you (and you Jeremy!) for your input. This thread will help decide how the blockquote spec changes to accommodate the use cases I outlined, so the more input the better. Thank you for your commentary, it is most appreciated. On Tue, Jul 12, 2011 at 2:52 AM, Bjartur Thorlacius svartma...@gmail.com wrote: I'm not arguing against rendering attribution. On the contrary, IMO user agents should render at least the title of the cited resource. This is a can of worms as authors will want control over both content and style. Attributes turned into content are harder to style than content. Also attributes tend to be for either humans (@alt) or machines (@datetime), so displaying attributes (for humans) that contain data (for machines) generally gives bad results. Datetimes will usually be presented in a localized format to humans. In the print use cases I found, sometimes attribution is inline after the last sentence and sometimes on a following line. This is in addition to having attribution in the prose surrounding the block quote, as currently recommended by the spec. How would the user agent know which way the author wants to present attribution? By fetching and reading a linked stylesheet. I think it's easier to style attributes then text nodes polluted with delimiters such as from and by that make reordering hard. More importantly, how is the author to know how the user wants attribution presented? Again I have no idea how a user agent would follow these rules. Arbitrarily showing one thing in one viewport size and something else at a different size would be a bug (arbitrarily meaning without author/user intervention, such as via CSS). A feature to one, a bug to another. The existence of the CSS height and width media features suggests that catering style to varying viewport sizes is desired by others than just me. I don't see why a user agent should seek an authors' permission to style a document for an unusually sized viewport, nor require users to write their own stylesheets instead of shipping customizable stylesheets. Love your phrase “superfluous screen space” btw ;) :P It's simply a question of blockquote Lorem ipsum footer a href=kennitala:2112952019 title=Bjartur ThorlaciusBjartur/a ontime datetime=1997-4-2the second April, 1997/time /footer /blockquote vs blockquote title=Bjartur Thorlacius datetime=1997-4-2 cite=kennitala:2112952019 Lorem ipsum /blockquote You've got two additional problems in your example: * currently only thetime,ins anddel elements accept the datetime attribute, and this isn't even a valid datetime value (you wanted 1997-04-02) Ops, you're correct; this should've been 1997-04-02. I'm proposing adding a datetime attribute to blockquote. * the cite attribute must be a valid URL, and is for providing a link to more information about the quote (generally its source) – you can't use it for non-URL data For a lack of a valid URI identifying myself, I used an unregistered uri-scheme (kennitala) and my national ID as the scheme-specific part. The exact URI in question is unimportant to the example, but I see no reason to restrict values of cite to locators only, as opposed to identifiers in general. Quoting books identified by ISBN numbers seems like a good enough use case to me. This proves Jeremy's earlier point about attributes being a bad place to store data. Unless you look at the source you’d never notice these mistakes. Sure I would, had I actually tried to, say, render them or validate before posting them on the Internet. I refrained from doing so as I knew this to be invalid markup, anyway. Where datetime to be a valid attribute of blockquote I also note that yourfooter example contains a lot more content, the visible part being “Bjartur on the second April, 1997”. A potential rendering of the attributes in your second example would probably be something like “Bjartur Thorlacius 1997-04-02, which I think isn’t as good. This refers to my first point about authors wanting to control the content. No, that would be quite an odd rendering. More likely renderings: Þann annan apríl 1997 skrifaði Bjartur Thorlacius: Lorem ipsum On the second April, 1997 Bjartur Thorlacius wrote: Lorem ipsum “ Lorem ipsum — Bjartur Thorlacius It all depends on the user's localized stylesheet. Note that a datetime in a time element would have to parsed just as date in a datetime attribute of a blockquote. They're both machine readable (and that's the best way to internationalize dates). Finally two other strikes against attributes are they're harder for people learning HTML (which is one reason we havesection over role=section etc), and we already have three (I’d argue) perfectly good elements for the data you are suggesting adding via attributes: *footer for following-line attribution and notes *time for datetime information *a andcite
Re: [whatwg] Call for Clarification of the Menu Element Et Al.
Þann lau 9.júl 2011 04:29, skrifaði Hugh Guiney: 6.1 On that note, why is the spec enabling the use of unstyled spans to achieve alternative rendering? Doesn't this give meaning (however contextual) to an element that is supposed to be semantically neutral? Can you think of any other uses for spans? Theoretically you could just want to identify text for later reference, but this need is better served by divs. If you want to reference a few words, you're probably better off quoting them (and citing a greater resource containing those words and context).
Re: [whatwg] input type=password... restrict reading value from JS?
Þann sun 10.júl 2011 08:08, skrifaði Alex Vincent: /** * Check if a password field's value matches another. * * @param otherPassword Another password element. * * @throws Error if this.type != password * @throws Error if other.type != password * * @returns Boolean True if the fields match. */ boolean passwordEquals(in HTMLInputElement otherPassword); I believe this to belong to CSS. User agents could either ask or require users to input error-prone and important fields twice, without submitting the same value twice. This could be the default rendering (in some UAs) for strong inputs (i.e. input descendants of strong). This has the potential benefit of allowing media-aware prefixes for locales where that makes sense (as in 'Retype Password' vs 'Confirm Password'). Note that the confirmation input in http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-required-attribute is optional. !DOCTYPE html titleRegister a FooBar account/title form action=register method=POST labelUsername input name=user required/label stronginput type=password name=pass required/strong /form /** * Check the strength of the password. * * @param type The type of check to execute. * * @returns 0 if dangerously low security * @returns 1 if soon-to-be-deprecated low security * @returns 2 if adequate security * @returns 3 if good security * @returns 4 if strong security * @returns 5 if entropy-death-of-the-universe security :-) */ unsigned octet passwordStrength(in DOMString type); I don't think this is a good idea. Can't user-agents warn about insecure passwords without the help of author-supplied scripts?
Re: [whatwg] The blockquote element spec vs common quoting practices
On 7/8/11, Jeremy Keith jer...@adactio.com wrote: Bjartur wrote: Citation will most likely contain the cited resource (@cite), the title of the cited resource (@title) and the date and optionally time of the quote (@datetime?). All three of which are invisible and so do not match the use cases that Oli has outlined. At least @title has a tooltip but the @cite attribute has proven to be a complete disaster, unsupported by user agents and ignored by authors, I'd like to reemphasize that: *unsupported by user agents* So you're saying that because attributes aren't rendered by default, user agents will ignore them and thus we should not use them? Why can't we fix UAs? Putting attribution inside blockquotes seems like a hack around lax support for attributes. That what's CSS is for. precisely because it is *hidden* metadata. http://www.well.com/~doctorow/metacrap.htm Yes, people lie. Unless you're arguing that using attribute syntax will encourage misquoting, I'll regard this article as interesting, correcting and unrelated. The article argues against searching for information in uncensored repositories of structured data prone to spamming, not typing footerasdf/footer instead of title=asdf. So I think that we can learn from the history of the @cite attribute in that it shows us how *not* to do it. But is it really possible to mark such citations up without presentational elements? I'm not sure I understand the question. Do you mean presentational as in not conveying semantics or presentational as in visible? Not conveying semantics. I'm not arguing against rendering attribution. On the contrary, IMO user agents should render at least the title of the cited resource. Interactive user agents should additionally make the cited resource available in manner similar to how they present other hyperlinked resources. Additionally user agents with superfluous screen space may render the datetime. Handheld renderings should of course not display the datetime without user interaction, but reserve the screen estate for more critical information, such as the quotation itself. It's simply a question of blockquote Lorem ipsum footer a href=kennitala:2112952019 title=Bjartur ThorlaciusBjartur/a on time datetime=1997-4-2the second April, 1997/time /footer /blockquote vs blockquote title=Bjartur Thorlacius datetime=1997-4-2 cite=kennitala:2112952019 Lorem ipsum /blockquote
Re: [whatwg] The blockquote element spec vs common quoting practices
Þann fös 8.júl 2011 11:20, skrifaði Jeremy Keith: 3) The solution that Oli has proposed (allowing footer within blockquote to include non-quoted information) is an elegant one, in my opinion. I can think of some solutions that would involve putting the attribution data outside the blockquote and then explicitly associating it using something like the @for attribute and an ID, but that feels messier and less intuitive to me. Simply allowing a footer within a blockquote to contain non-quoted material satisfies the design principle Avoid needless complexity. http://www.w3.org/TR/html-design-principles/#avoid-needless-complexity Simple solutions are preferred to complex ones, when possible. Simpler features are easier for user agents to implement, more likely to be interoperable, and easier for authors to understand. Citation will most likely contain the cited resource (@cite), the title of the cited resource (@title) and the date and optionally time of the quote (@datetime?). Further information could be put into other attributes as necessary. This seems simpler than cluttering the quote and citation together in the blockquote, but just throwing everything inside of the blockquote may very well be easier to implement. But is it really possible to mark such citations up without presentational elements? !-- 2112952019 = my national ID -- blockquote cite=kennitala:2112952019 title=Bjartur Thorlacius pLook ma, no lt;footer!/p pI think we should keep citations outside of lt;blockquote's contents as citations aren't part of the quote per se, but metadata on the quote and the quoted resource/p /blockquote
Re: [whatwg] AppCache-related e-mails
Þann fim 7.júl 2011 05:30, skrifaði Felix Halim: On Thu, Jul 7, 2011 at 3:57 AM, Karl Dubostka...@opera.com wrote: http://uhunt.felix-halim.net/id/339 I'll look into your site when I've slept, but FYI, you're mandated to provide a title for your document. You should probably provide a title of uHunt, and append to the title's innerHTML as further information becomes available. [/nitpick]
Re: [whatwg] AppCache-related e-mails
Þann fös 1.júl 2011 03:22, skrifaði Felix Halim: I'm looking for a solution that doesn't require modifying anything except adding a manifest. I recommend fixing your website. As others have stated, this has practical benefits, in the online as well as the offline case. As I said before, separating dynamic from the static will work, Great! however, if we don't have pageStorage, even we have a clean dynamic separation, it will quickly run out of space if we use localStorage since the localStorage quota is per domain. Nobody's forcing you to use localStorage. How do you figure using pageStorage or localStorage will be less work than using iframes or other linking methods already proposed? Let's see an example: I have a dynamic page with this url: http://bla/page?id=10 The content inside is changing very frequently, lets say every hour. Of course, I want the browser to cache the latest version. Then specify the applicable HTTP headers with informative values. HTTP caching hasn't stopped working, nor is it barred from improving. There is space for implementations to improve while complying with current specifications. All you have to do is split dynamic resources from static, read the RFC and send the appropriate headers. Of course this method has the drawback of requiring a request/response pair for every resource transferred over HTTP. So, it seemed that AppCache is a perfect fit... AppCache is no magic bullet. Don't use it if you figure it isn't a perfect fit. I then add the manifest to enable the App Cache, and what do I get? Everytime I open that URL every hour, I ALWAYS see the STALE version (the 1 hour late version). Then few seconds (or minutes) later (depend on when the AppCache gets updated), I refresh, then I got the latest content. Annoying, right? FYI, HTTP has already resolved this issue, by forbidding implementations from returning a stale version by default under normal situations or without warning In this case, I better off NOT to use App Cache, since it brings the old content everytime. Right. Bad App Cache. Now, let see the alternative: I build a framework to separate the dynamic from the static. I have to make it so that only ONE MAIN PAGE get cached by the app cache. So, my URL can NO LONGER BE: http://bla/page?id=10 But it has to change to: http://bla/page#!id=10 Why do I have to do this? it's because if I DON'T, then each page will be stored on different App Cache, and the stale by one still occurs! That is, http://bla/page?id=10 and http://bla/page?id=11 Will be on DIFFERENT AppCache! In that case, my cleanly separated static and dynamic will have no effect! Because all the statics get duplicated for each App Cache. It will be the same as if I don't have the framework! I'm not following your line of thinking. Why do you insist on using an App Cache for each page rather than a shared cache for all your resources? So, to make the AppCache only cache one static framework, I have to make my page such that it is served under ONE url: http://bla/page Then take the #!id=10 as non url (or ajax bookmark). This way, the AppCache will only cache ONE of my static framework, and MANY dynamic content inside it. Guess what? All the incoming links from other blogs are now broken! Of course I can make a redirect, but redirect is AGAINST making the web faster! I think Facebook did the #! thing a while ago, then they abandoned it, why? Ok now I'm happy with my framework and the redirect, and guess what? Soon, I have other pages with #!id=11, #!id=12, ..., #!id=1. All of them are important and I wan't to cache them and I uses the localStorage (or indexedDB) to cache the dynamic content of those pages. Note that even though the dynamic content is dynamic it doesn't mean that: http://bla/page?id=10 has shared data with http://bla/page?id=11 It can be totally different unrelated dynamic content. id=10 dynamic content is entirely different from id=11 dynamic content. However, since I use localStorage to cache the dynamic content, ALL OF THEM are limited to the quota of my domain. My 5MB localStorage domain quota will quickly run out of space. Are you certain that users wish to archive every single dynamic resource they fetch from your site? Disposition of any significant amount of storage should be in the hands of the user, if indirectly through the user agent. Take handhelds. If only I can store the dynamic content into a pageStorage (assuming different URL - including the shebang bookmark has different pageStorage), then I won't be running out of storage if I keep one page within 5MB. So And you're sure this is a good thing, because? http://bla/page#!id=10 You *can't* allocate a quota per URI fragment, as a script in the page could create new ones as wanted. Then I would be very happy with the new framework. Since it will store very compact static App and very compact dynamic content. It's a win win for everyone, nothing
Re: [whatwg] AppCache-related e-mails
Ask HTTP implementors to store a potentially stale fallback copy for offline use when an authoritative copy is unavailable. Even HTTP caches are allowed to return stale responses as long as they warn their clients (so they can warn their clients or fetch an authoritative copy via another route). Browsers should keep copies of the most used entries for offline use. It's probably a matter of minor tweaking, considering that mainstream browsers support offline modes already. From http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.1.5: In some cases, the operator of a cache MAY choose to configure it to return stale responses even when not requested by clients. This decision ought not be made lightly, but may be necessary for reasons of availability or performance, especially when the cache is poorly connected to the origin server. Whenever a cache returns a stale response, it MUST mark it as such (using a Warning header) enabling the client software to alert the user that there might be a potential problem. P.S. Your hypothetical major overhaul should probably involve splitting the dynamic content into separate resources linked to from a static main page/index using iframes.
Re: [whatwg] Interpretation issue: can section be used for extended paragraphs?
On 6/14/11, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Jun 14, 2011 at 2:04 AM, Markus Ernst derer...@gmx.ch wrote:
Consider:
I like apples, pears, grapes, but not bananas. Nor do I like
peaches.
and:
I like
* apples
* pears
* grapes
but not bananas. Nor do I like peaches.
The difference between those two is presentational, not semantic. Each
is a single paragraph.
Well, in standard English, the prose list would actually read I like
apples, pears, and grapes, but not bananas.. You'd have to somehow
mark up and hide the and when presenting it as a structured list
instead of a prose list. This suggests that there *is* a semantic
difference between the two. It's a subtle difference, to be sure, but
it's there.
The difference isn't semantical. I'm not educated about archaic
English, but in my language, all items were seperated by an ok, as
in eppli ok perur ok greip but nowadays the norm is to somehow
hide all the oks but the last one (probably for brevity). HTML has
more structure, and can nest lists without ambiguity, so the and is
unnecessary.
However, if rendering lists inline, and thereby loosing this
structural nature of lists is desired, it's the job of CSS.
ul
liapples
lipears
ligrapes
/ul
but not bananas.
With the following stylesheet:
ul { display: inline; }
ul li :after { content: ', '; }
ul li:last-child :before { content: 'and'; }
ul li:last-child :after {content: '';}
Re: [whatwg] Support for page transitions
On 6/9/11, Mikko Rantalainen mikko.rantalai...@peda.net wrote: 2011-06-07 18:07 EEST: Bjartur Thorlacius: Elaborate; they both refer to the next resource in a sequence of documents. Note that a document may be an element in multiple sequences of documents. Notice the word linear. I think rel=maybe-next would describe what I'm thinking. Or perhaps rel=next should be changed to mean maybe next. Wizards are inherently linear; their reason d'etre is links to subsequent forms for the user to fill in. If the wizard provides multiple links for the user to select one, they can use multiple rel=next links. Forking wizards thus consist of multiple linear sequences of documents. Example: A - B - C A - C A - D - B - C A would link to B, C and D, D to B and B to C. IIUC this is valid. There may of course be more forking points. Backup of form contest is one thing and I'm already using user agents that allow this at least via extensions. However, submitting the draft to the server instead allows additional application specific processing / mutation for the form when user later returns to it. For static pages, there's a less need for features like this. It seems to me that such mutation would preferably be done client-side (using JavaScript), so the user can benefit sooner. It seems odd to make the user fill in a form partially, submit a draft, and then edit a mutation thereof. But only if he pauses his work to submit the draft, and only on the data he put in prior to submitting. And not give him the mutated version if he fills the form in without pause. If you really want the user to get the mutated version, you return another form prefilled with mutated values when the user submits the first one. That's possible using ordinary submits. Can you provide use cases for this server-side mutations of drafts? Also note that currently rel=next is not allowed on input type=submit, unless I've understood incorrectly. Having an input type=submit rel=prev is far from straight-forward. You should have a document with hyperlinks of rel=next and rel=prev and forms. The forms themselves contain no links to subsequent forms. The user agent should fill in a form, submit it in another browsing context and proceed to the next one (allowing the user to select the next one when the document suggest multiple). There's nothing forbidding the user agent from showing fancy transitions while loading the next document, progressively rendering the form as it becomes available. [Current HTML draft, Form submission algorithm, step 15]
Re: [whatwg] Session Management
On 3/11/11, Dave Kok upda...@davekok.net wrote: This may very well be a natural consequence of having a proposal like this implemented. But this would assume that implementers feel that having a logout button embedded into documents is considered superior then having a UA provided logout button. Otherwise such a thing would never happen. Also authors have the freedom to use either a custom authentication method or a UA provided authentication method. Though I too prefer the UA provided authentication method we can't force authors to do so. A UA provided logout button alone thus not cover custom Authors shouldn't be able to force users to use their homebrew (NIH, anyone?) authentication UI instead of the familiar one my browser of choice sports. Whatever you do, don't encourage authors to use authentication methods that my UA doesn't understand, and will thus not be able to provide an interface for.
Re: [whatwg] Support for page transitions
On 6/7/11, Mikko Rantalainen mikko.rantalai...@peda.net wrote: Note that the next page button may or may not match with rel=next and as such, I think that there should be additional method for Elaborate; they both refer to the next resource in a sequence of documents. Note that a document may be an element in multiple sequences of documents. If I understand correctly, the feature you want that's not supported by rel=next and rel=prev is sending a draft to a server when switching forms. Even better than that would be saving a draft for every input filled by a user. This draft can be written to a local disk, or stored at networked servers for global access, for the user agent to refill when the user revisits the form. I think some user agents already implement the latter, so that leaves bells, whistles and transitions.
Re: [whatwg] Content-Disposition property for a tags
On 6/6/11, Boris Zbarsky bzbar...@mit.edu wrote: My point was that there should be _a_ standardized way that sites can use to get consistent behavior across browsers. Content-Disposition headers see like that way to me. More importantly there should be an implementation defined convention so users get consistent behavior across sites. I don't see why authors should care so much how users identify documents internally, when the original point (type information) is nullified by filename sanitization crucial to security. Browser are able to deduce descriptive and rather unique names from the title, terser ones from the URI and allow the user to choose his own. You'll never able to assume your suggestion will be used, anyway.
Re: [whatwg] Content-Disposition property for a tags
On 6/5/11, Boris Zbarsky bzbar...@mit.edu wrote: Why need they be? This isn't Bittorrent. I think you completely misunderstood my mail... the point is that browses do NOT all use the last non-empty path component; some try to guess a filename based on the query params, in various ways. No, I understood - my point that it doesn't matter; browsers need not standardize on variables yo deduce filenames from*. * With the exception of mirroring user agents such as wget (who don't conform to my definition of 'browser')
Re: [whatwg] Content-Disposition property for a tags
On 6/3/11, Boris Zbarsky bzbar...@mit.edu wrote: http://mysite.org/generate_progress_report.php?quarter=Q12010 When saving, it would be good to use something like Progress report of Q1 2010 as the filename. But that's not part of the URI in any sense. So you're suggesting using the title as the filename. In that case, the a element has a @title attribute already. a href=http://mysite.org/generate_progress_report.php?quarter=Q12010; title=Progress report of Q1 2010progress report/a Note that some browsers will do weird parsing of the query params to attempt to extract a useful filename. That seems strictly worse than just using Content-Disposition. That's slightly better than just using the last non-empty path component, though. But yes, in the general case, the filename should be extracted from the title. Note that filenames being verbose by default is a good thing (to avoid accidental collisions). The user can provide short, easy-to-type filenames that he can remember himself. I strongly disagree. I think browsers that use the Content-Disposition filename for attachment but not inline are just buggy and should be fixed. FWIW MSIE9 seems to honor the filename hint with inline (contrary to the test results mentioned earlier in the thread). Of course it sounds like your position is that they should not use the filename for attachment either... (in which case you disagree not only with me, but with most of the web). ... but agree with me. The filename hint is useful for providing filename extensions. Honoring these irrespective of the Content-Type is dangerous. I recommend browsers strip the first dot and all following characters from filename hints - but then they could just as well ignore it.
Re: [whatwg] Content-Disposition property for a tags
On 6/3/11, Boris Zbarsky bzbar...@mit.edu wrote: On 6/3/11 11:46 AM, Bjartur Thorlacius wrote: Note that some browsers will do weird parsing of the query params to attempt to extract a useful filename. That seems strictly worse than just using Content-Disposition. That's slightly better than just using the last non-empty path component, though. It's not, because they're not consistent about it... Why need they be? This isn't Bittorrent. Use the last non-empty path component for a short name prone to accidental clashes, or the title for a verbose, unportable and descriptive name. It's purely a hint for user convenience (so they don't have to invent their own names or retype the title). What a file is named on a client's machine is purely the client's matter.
Re: [whatwg] Content-Disposition property for a tags
On 5/26/11, Michal Zalewski lcam...@coredump.cx wrote: Keep in mind that the mechanism *is* extremely imperfect. It only works for MIME types and extensions recognized by the browser (which is a small list). There's a large disconnect between this set, the set handled by the OS, and the actual logic used to control content disposition later on (much more messy on Linux than on Windows, interestingly). On Linux you may have comprehensive mailcap lists in /etc, or better yet the filename extension to MIME type mappings used by httpds. Unless it becomes common for file systems to support MIME type metadata for every file, and for all client applications to honor it, I really think that giving the markup such control over content disposition does more harm than good. Browsers need to recognize the filename extensions to be able to utilize the filename hint securely, and the filename hint's raison d'être is providing filename extensions in case the browser doesn't know it. It's therefore harmful when it's potentially useful.
Re: [whatwg] Unlimited pageStorage for App Cached web pages
On 5/31/11, Felix Halim felix.ha...@gmail.com wrote: On Mon, May 30, 2011 at 10:39 PM, Bjartur Thorlacius svartma...@gmail.com wrote: The dynamic resources only updated if the user visit the particular app cached web-page. Yeah, that's logical. Caches should still be allowed to refetch resources just before they're expected to be used. I might want my home computer to fetch the latest news in the morning and evening, so I can start reading when I wake up and when I get home from school. Remember that the dynamic resources I'm talking about here is NOT shared between other web-cached pages (even they are in the same domain). That's fine. I don't think caches need to know that, but I'll get back to you after some sleep. It may be hard to get quotas right; but multiple HTML documents *could* link to the same resources. I think quotas should only be enforced per resource and on the user agent, leaving the user agent to use the quota for small files only as effectively as it can, e.g. by keeping only frequently used resources. The former is easy to achieve, but user agents tend to throw away stale versions as to not present outdated information to the user and to save storage space. The user agent only need to keep the latest version. It's fine to throw away the outdated one if you have the latest. Sorry, I meant potentially stale. User agents should of course not keep obsolete versions of resources when they have fresh ones, but they may end up with versions of resources are not fresh. In this case they SHOULD validate or refetch the resource - except when working offline. You want user agents to fetch the latest version whenever possible, but keep an old copy for when your servers are unreachable. The whenever possible is when the user revisit the cached page. ...and a cache has a fresh copy or an authoritative server for the resource is reachable and responsive. The old here means the latest version that was cached.. Yes. 5MB ought to be enough for anyone. You were joking, right? :D Yeah, I'm kidding. :P I believe quota size should be decided on case-by-case basis (unlike localStorage where it's probably useful to make assumptions as to the available storage space). 5MB for each App Cached web-page is probably OK. However, 5MB localStorage quota for each domain is NOT OK. The right amount to reserve for caching depends on the scarcity of space on the user's machine. If all you want to do is store mutable resources for offline use and validate them if possible, but returning the cached entry (or entity) if validation is impossible, simply serve the resources with an Expires header set to a date in the past. Here is an example of how I want the App Cache to behave: First, it always try to fetch the main page, and all its static/dynamic resources and display it (just like normal web page). Then some time later, if the user want's to visit the SAME page again but the user is offline or the server is unavailable, then the latest cache of the page is displayed. HTTP user agents MAY implement the behaviour you describe; i.e. use potentially stale entries when validation (checking if it's fresh) is impossible - as long as that doesn't happen normally. I don't consider working offline normal. Caches are free to serve potentially stale entries as long as they they disclose how old they are (so the user agent can determine if it's usable, or warn the user). My impression is that HTTP caching fulfills your needs and that the HTTP specification doesn't forbid the behaviour you prescribe. Thus you're free to implement your ideal behaviour without modifying any specifications. Are you unable to use HTTP caching? In the sense, it's exactly like working offline mode whenever the user is offline or the server is not responding. Why can't you use offline mode? Serve the dynamic content with the expiration date set to the past. That way the UA can store it for offline use if it has enough storage space at it's disposal (making space for it using an implementation defined cache algorithm such as LFU). The current App Cache design updates the cache to the latest version in the background when the user visit the page for the second time and then it needs to refresh the page to actually update the display. This is annoying since the user will first see stale data, then a few second later, it's updated with a giant refresh (including all the static resources). This is because the App Cache is too COARSE grained. It doesn't know what actually changes (which data are static, which data are dynamic). That is another reason why we need pageStorage: to separate the dynamic and the static resources. Disclaimer: I'll have to do some reading on App Cache; I don't even understand why good ol' HTTP caching doesn't do the job. HTTP caches know which resources are static or dynamic, as the HTTP server tells them. A networked cache will return the static resources immediately
Re: [whatwg] Unlimited pageStorage for App Cached web pages
Þann mán 30.maí 2011 03:42, skrifaði Felix Halim: Hmm.. yes, I think unlimited is a bad word (I just use it because currently App Cache quota is unlimited). Let me explain my need for pageStorage in a different way: Suppose I have a web page and want to store it in an App Cache. This web page requires a few resources (.ccs, .js, images, etc..). But all of them are static resources. I want to store dynamic resources as well for that particular page only (not shared). Think of the dynamic resources as data that changes from time to time for that particular page only. localStorage can be used to store the dynamic resources, but localStorage has very limited quota and it is shared to the entire domain. Different unrelated pages in the same domain will use the shared quota! The following is how I understand your requirements; please correct me where correction is due. You've got two types of resources: 1. static resources, to be retrieved once and cached indefinitely 2. dynamic resources, to be updated whenever possible while always keeping the last version The former is easy to achieve, but user agents tend to throw away stale versions as to not present outdated information to the user and to save storage space. You want user agents to fetch the latest version whenever possible, but keep an old copy for when your servers are unreachable. Currently I can hack the App Cache to simulate the pageStorage like this: We can turn one of the .js files dynamic by updating the .js file, then edit the MANIFEST file a bit, so that the browser re-download *ALL* the resources again. This way, the .js file quota gets in the App Cache quota which is currently *UNLIMITED*. But this hack is very costly, and inconvenient. 5MB ought to be enough for anyone. If all you want to do is store mutable resources for offline use and validate them if possible, but returning the cached entry (or entity) if validation is impossible, simply serve the resources with an Expires header set to a date in the past. That way caches SHOULD validate the response before reusing it, but may reuse it without validation under abnormal situations, such as when working offline. Of course, doing this for all resources doesn't make sense when storage space is scarce. In that case discard stylesheets, huge videos, heavy graphics other files with a high noise to content ratio.* If your (or your client's) cache doesn't do that already, you're free to modify it, or pay someone to do it for you. *Warning: The result of calculating the noise to content ratio of CSS files is undefined.
Re: [whatwg] Unlimited pageStorage for App Cached web pages
On 5/28/11, Felix Halim felix.ha...@gmail.com wrote: To summarize, the pageStorage offers unlimited storage for dynamic content for the App Cached web pages. User agents may store expired pages for offline use. Internet Explorer and Firefox have 'Work offline' modes automatically enabled on complete disconnection from the network. Currently, only cached pages and sites explicitly selected by the user are available offline, but given enough disk space, user agents might keep all files of MIME type text (e.g. text/html and text/plain) - or even all files. The variation on constraints between systems is such that even looking only at my desk there's a system with over 1.7GiB of free read-write memory (0.5MiB magnetic, 1.3GiB volatile RAM) and another one with under 300MiB (volatile RAM). I don't want authors to be able to use up my memory by storing most or all content for offline use, nor to unnecessarily loose access to content when storage space is plentiful.
Re: [whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider
On 5/16/11, Ian Hickson i...@hixie.ch wrote: On Mon, 16 May 2011, Adam Shannon wrote: I'd rather see UA's implement better controls on their end than see an API which could be largely abused. (Drag and drop browser controls over tons of sites asking for permission to be the default.) I agree. Note that the spec doesn't say there should be a dialog box at all; it's left entirely up to the UAs. Then why add an API when we've already got (IMO superior) declarative markup? The user has to consent. Even confirmation prompts may not be a usable authorization mechanism (as most users generally don't understand them). Use case: User wants to add a search provider. Requirements: A GET form from a site user's consent The chosen solution should be easily adaptable if not usable for publishing as well as searching. Creating a hyperlink to a POST form (without the search relation) should be suitable for microblogging. Solutions: A document advertises a form to the browser; if not installed: the browser advertises the form to the user; the user commands the browser to install the form. document - browser browser - user -- the site is never informed A document ask the browser if the user has installed the form; if not: begs the user to install it; the user asks the document to ask the browser to install the form; the document ask the browser; the browser asks the user whether it should proceed; the user consents. Or do you mean that a script is to ask the browser without user interaction? document - browser document - user browser - user Security considerations: In the case of an API a script bundled with a document may at any point ask for form installation, irrespective of isSearchProviderInstalled making isSearchProviderInstalled redundant, as if it's installed (or blacklisted as in explicit user refusal to install) the call would be ignored anyway. Also, my UA would probably always act as if the form was installed, to protect agaisnt blackmailing á la Facebook scams and sites funded by getting money for endorsing (unwanted) forms.
Re: [whatwg] Proposal for a web application descriptor
On 5/6/11, Charles McCathieNevile cha...@opera.com wrote: On Thu, 05 May 2011 21:41:24 +0200, Bjartur Thorlacius Of course, if the site requests coordinates, it's up to the user whether they come from /dev/gps or /dev/tty (or /n/3D Globe). Yeah, in principle. But given that most users aren't going to symlink /dev/gps via their hand-crafted code to decide what to say (largely because browsers just ask Google where you are instead based on visible Wifi) in practice the question is how to build reasonable UI that the users actually understand. The point was that they user could choose between the location provided by their GPS and Click on a spot on the globe representing the Earth (ignoring whether the selection is the user's location or not). This would force users to make an informed choice (as there's no button labeled OK).
Re: [whatwg] Proposal for a web application descriptor
On 5/5/11, Charles McCathieNevile cha...@opera.com wrote: On Thu, 05 May 2011 00:12:06 +0200, Bjartur Thorlacius svartma...@gmail.com wrote: On 5/3/11, Cameron Heavon-Jones cmhjo...@gmail.com wrote: There are a number of resources which are thought of having an 'application' scope which may make sense to be collated into a single manifest and with the ability for an agent to manage it as such. Yeah, if a single entity edits and signs multiple resources, it's unreasonable to trust one but not another. If I understand correctly, I disagree. I might trust a given entity sometimes, or with some kinds of information, without wanting to simply say sure whatever you want. That's probably for the hard-to-use mode in the UI, but I think it's legitimate. In practice, even given something as simple as twitter's geolocation request I *sometimes* allow it to know where I am and sometimes don't. In that case you wouldn't grant anyone a carte blanche access to your location, but authorize or forbid each request. I meant that users probably wouldn't want to permanently authorize http://twitter.com/A but not http://twitter.com/. Of course, if the site requests coordinates, it's up to the user whether they come from /dev/gps or /dev/tty (or /n/3D Globe).
Re: [whatwg] Proposal for a web application descriptor
On 5/3/11, Cameron Heavon-Jones cmhjo...@gmail.com wrote: I would agree a command-level authorization is a better default, if only because it is necessary to have this level of granularity available. Agreed. The quantity of permission requests can be managed in an effective manner by the agent allowing the user to store their preferences for the next command or as a universal setting. If you manage to inform users that they'd then be authorizing for every purpose, usually without notice, not just for obeying the previous command. This is similar to what firefox does for launching unknown file types, session restore, or lots of other functions, although it would be in the context of a web application itself. How so? [snip stuff I completely agree with] For web applications to specify their required permissions would seem to introduce a duplication of specification. If a web application includes an image file upload which the user chooses to capture from webcam, first how is the application to know that the user would use a web cam? and second It isn't to know, nor to care. It receives an image, not a camera. what additional information is being specified in the permissions descriptor which wasn't already deductible from the inclusion of a file upload? This would additionally impose the scenario where applications include the use of some restricted system resource but fail to document the use in their descriptor, not an insurmountable problem but it draws any usefulness into question. Same problem as with Firefox on Android. There are a number of resources which are thought of having an 'application' scope which may make sense to be collated into a single manifest and with the ability for an agent to manage it as such. Yeah, if a single entity edits and signs multiple resources, it's unreasonable to trust one but not another.
Re: [whatwg] Small consistency issue with HTML5 nav element examples
On 5/4/11, Ian Hickson i...@hixie.ch wrote: IMO browsers should implement link. link should be implementable cross-browser in CSS. Unfortunately, what we want and what we get don't always match. :-) I'll be a dick and quote your sig: Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' On a more serious note, implementing link can't be that hard. I'll probably patch my UA myself when I get the graphics layer working on my system (or just use links2). But I'm slowly coming to the conclusion that a should be used for creating hyperlinks that seem to belong to head, in a tree of htmlbodyasidea, for compatibility with mainstream UAs. My actual concern regard navigation links not forming a part of the linear body of the document, but still being in body. Navigation links will most likely be rendered out of band, potentially only on demand and paged/scrolled seperately from the body, or at the end of the document in one dimensional renderings (such as audio and text streams). They might even be triggered without being rendered at all, such as by scrolling out of range of the current document. It seems most authors desire far more control over their navigation links. On many pages, it's almost as if the navigation links are more important to the authors than the content, at least when you look at the amount of effort put into them... Sadly, the things authors desire may conflict with the things users desire. I also desire control over navigation links (among many other things). From authors, I desire only content. Bjartur Thorlacius yet another End-User(tm)
Re: [whatwg] Indicate a file name for data: URLs?
On 3/21/11, Philip Jägenstedt phil...@opera.com wrote: On http://foolip.org/microdatajs/live/#json I have a Download it! function which uses data: URLs to save JSON generated by JavaScript. The only real limitation with this approach is that one cannot suggest a file name, so in Opera the suggested file name is default. Sorry for my naïvety, but does there need to be a suggested file name?
Re: [whatwg] INCLUDE and links with @rel=embed
On 4/28/11, Ian Hickson i...@hixie.ch wrote: On Thu, 28 Apr 2011, Bjartur Thorlacius wrote: All current UAs would understand the link (and most probably present it to the user). Inline presentation is an optional luxury: the important thing is getting the media across. I, for one, can't find any sign of source support in wget, and a few other non-mainstream UAs. Well for video fallback people are likely to use a as well, but I don't think it makes sense to force every source to be a link. Writing both source and a for every source seems like unnecessary duplication to me. The primary difference between the two is that the resource referenced by the former is to be displayed inline, but the resource referenced by the latter is to be accessible interactively. a style=content: url(attr(href)); href=/usr/videos/lolcatzFunny cats jumping around/a. Ok, this isn't valid CSS, but you get my thinking (I hope).
Re: [whatwg] INCLUDE and links with @rel=embed
On 4/28/11, Ian Hickson i...@hixie.ch wrote: On Sat, 11 Dec 2010, Bjartur Thorlacius wrote: An UA can support the scheme used without supporting the source element. If A was used, they just had to support A and the scheme. It's still not clear to me what problem this would solve. I see what it would do, but why would we want that? Backwards-compat. It's so UAs that don't support source can still grasp some semantical information from the element. Do you have a concrete example of how that would work? What current UAs usefully grasp such information in such a context? All current UAs would understand the link (and most probably present it to the user). Inline presentation is an optional luxury: the important thing is getting the media across. I, for one, can't find any sign of source support in wget, and a few other non-mainstream UAs.
Re: [whatwg] Physical quantities: var or i?
On 4/14/11, Christoph Päper christoph.pae...@crissov.de wrote: Jukka K. Korpela: varc/var would be odd, wouldn't it, since the symbol denotes a universal constant of nature. It would not, ‘c’ is merely a variable with constant value. Well, a constant isn't really variable any more, is it? I thought var was meant to mark up text that couldn't simply be 'copypasted' without filling in the unknowns (free variables). Defined variables (whether in source code or formulae) do not conform to that definition. So, coderm -r var$path/var/code would conform (as a reply to the question how does one remove a (potentially non-empty) directory on *nix?) as $path is undefined, but codevari/var++/code would not, as i isn't ment to be substituted. varE/var = varm/var·varc/varsup2/sup Or math, eventually. Or, in the meantime, code (IMHO, at least). It's not source code for a computer program, but for all purposes and intentions I can think of, source code and formulae can be treated equivalently. The spec formally requires 'computer code,' i.e. sth understood by a computer, making my suggested usage non-conformant.
