Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts

[Bjartur Thorlacius]

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

[Bjartur Thorlacius]

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  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] / not needed

[Bjartur Thorlacius]

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:
> > 
> > http://www.w3.org/2000/svg"; viewBox="0 0 900 1135">
> > A painting by Edvard Munch, commonly known as "the scream".
> >  > 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";);
> >  }
> > }
> > ]]>
> > 

Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)

[Bjartur Thorlacius]

On 5/13/12, Kornel Lesiński  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] Implementation complexity with elements vs an attribute (responsive images)

[Bjartur Thorlacius]

On 5/13/12, Kornel Lesiński  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 /// 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] Search-suggestions without scripting

[Bjartur Thorlacius]

On 5/5/12, Ian Hickson  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] Specify href target with HTTP headers

[Bjartur Thorlacius]

On Wed, 14 Mar 2012 19:59:50 -, Christian Schmidt   
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  
 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] Prerendering and APIs

[Bjartur Thorlacius]

On Wed, 14 Mar 2012 15:35:14 -, Gavin Peters (蓋文彼德斯)  
 wrote:

We're having great luck in Chrome with .  If

Does  not trigger this feature?

Re: [whatwg] Specify href target with HTTP headers

[Bjartur Thorlacius]

On 3/8/12, Christian Schmidt  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 . 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

[Bjartur Thorlacius]

On Wed, 07 Mar 2012 22:19:17 -, Christian Schmidt   
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  or  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  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  and  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] feedback

[Bjartur Thorlacius]

Þ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,

href="http://www.google.com/url?sa=t&rct=j&q=l%C3%B6gberg&source=web&cd=2&ved=0CCwQFjAB&url=http%3A%2F%2Fwww.thingvellir.is%2Fsaga%2Flogberg%2F&ei=F69ST6T3OM6XOqGOnZEK&usg=AFQjCNEPLku9Nm5bsA12_oY9mV1gPH3Aeg&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 in form submissions

[Bjartur Thorlacius]

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

[Bjartur Thorlacius]

Þ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] Proposal: Deprecate registerProtocolHandler/registerContentHandler via Web Intents

[Bjartur Thorlacius]

Þ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

[Bjartur Thorlacius]

Þ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] Caching of identical files from different URLs using checksums

[Bjartur Thorlacius]

Þ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 . 
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

[Bjartur Thorlacius]

On Mon, 13 Feb 2012 19:12:09 -, Boris Zbarsky  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:


   
   
   
   

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] Deferring image load

[Bjartur Thorlacius]

On Mon, 13 Feb 2012 14:59:09 -, Boris Zbarsky  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 s dynamically  
pointed to prefetched  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

[Bjartur Thorlacius]

On Mon, 13 Feb 2012 14:17:28 -, Boris Zbarsky  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

[Bjartur Thorlacius]

On Mon, 13 Feb 2012 11:00:52 -, Kang-Hao (Kenny) Lu  
 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

[Bjartur Thorlacius]

On 2/13/12, Gray Zhang  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  and 
>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] add html-attribute for "responsive images"

[Bjartur Thorlacius]

On Wed, 08 Feb 2012 17:16:36 -, Anselm Hannemann - Novolo  
Designagentur  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.


type="image/gif">

 Nazi Cats
 Humans have been obsoleted.


type="image/gif">
 



As has been pointed out in the thread already, using  fallbacks of  
different media types may result in strange behavior, and is hard to  
implement correctly.

Re: [whatwg] add html-attribute for "responsive images"

[Bjartur Thorlacius]

If using a single  element for embedding in general would be
too hard on implementations (although the markup cleanliness is
tempting), can we not (re)use  for both animated and still 2D
images?

Re: [whatwg] add html-attribute for "responsive images"

[Bjartur Thorlacius]

On 2/7/12, Ashley Sheridan  wrote:
> The main problem I see with that is that the  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  tag
> as you'd still have full backwards compatibility.
>
What accessibility features, exactly? For compatibility, the deepest
child of  would be , 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 's being generally terrible for accessibility
has been established already.)

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Bjartur Thorlacius]

On Mon, 06 Feb 2012 20:08:05 -, Matthew Wilcox   
wrote:

On 6 Feb 2012, at 19:19, Bjartur Thorlacius wrote:
We're discussing HTTP here, so the content might just as well be raster  
bitmaps.


Are we? Why, what makes HTTP the relevant factor? SPDY is the future and  
already supported in two major browsers., As it compresses headers and  
multiplexes, I don't see the issue.


Sorry, my bad. We're discussing an application layer client/server  
protocol that can be used for transferring files that don't use CSS pixels.


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.


No, it means we as a standards body define which gets sent. The sensible  
thing is to send the maximum screen size in use on the device.


This is usually, but not necessarily known on page load. I think static  
viewport resolution and screen size is the 80% case we should optimize  
for, but others (who presumably print documents more often) disagree.


Again, read the proposition I mentioned and you'll find non of this is  
true. Extra headers would only be sent by the browser if the browser  
received a request for the client to send those headers.



Presumably, this would be decided upon authority-wide (in the URI sense)?

Trying to allow the application layer client/server file transfer protocol  
stateless may be overly purist and impractical, but I think highly  
descriptive s are a better solution.


--
-,Bjartur

Re: [whatwg] add html-attribute for "responsive images"

[Bjartur Thorlacius]

On Mon, 06 Feb 2012 21:23:37 -, Mathew Marquis   
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  markup pattern as the inspiration, with  
the use of media attributes on the  elements to determine the  
rendered source, and the inclusion of an --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  fallback.


Why not use a media attribute of ? That way you should get media  
type disambiguation for free.

--
-,Bjartur

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Bjartur Thorlacius]

On Mon, 06 Feb 2012 19:49:43 -, Boris Zbarsky  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] RWD Heaven: if browsers reported device capabilities in a request header

[Bjartur Thorlacius]

On Mon, 06 Feb 2012 18:59:14 -, Boris Zbarsky  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

[Bjartur Thorlacius]

On Mon, 06 Feb 2012 13:49:35 -, Matthew Wilcox  
 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

[Bjartur Thorlacius]

On Mon, 06 Feb 2012 18:58:00 -, Boris Zbarsky  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

[Bjartur Thorlacius]

On Mon, 06 Feb 2012 17:44:30 -, Boris Zbarsky  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

[Bjartur Thorlacius]

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 ,  and  (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?

[Bjartur Thorlacius]

On Wed, 01 Feb 2012 05:00:04 -, Brett Zamir  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

[Bjartur Thorlacius]

On Thu, 26 Jan 2012 21:43:07 -, Matthew Wilcox   
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:

Content

Written by: Person



Nothing tangible. It would serve my main use case of allowing s  
by respected authors to be rendered before other s 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

[Bjartur Thorlacius]

Þann fim 26.jan 2012 14:48, skrifaði Matthew Wilcox:

What's wrong with using a class on the  to identify the author
stylistically? It's already identified semantically by having their name
in the  itself, right (presumably in a  too)?
As in 

The situation only gets worse when you consider the different stylistic 
needs of various media. I might want the whole  rendered to the 
relatively large desktop screen of mine, but omit everything but 
authors' name or identity on my handheld screen. , 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 
s 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.



Example of Semantically Marking up Authors of Documents

 An Article Written by Bjartur
 This article was written to demonstrate how authorship might be 
marked up. I sure hope it's valid!

 
  mailto:bjar...@spam.la";>Bjartur Thorlacius
 

Re: [whatwg] Requests for new elements for comments

[Bjartur Thorlacius]

On Wed, 25 Jan 2012 22:26:31 -, Ian Hickson  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
s is undeniably useful. First-posters in a thread or syndication
may be styled differently from other posters,  by authors of
outer  may be emphasized in some way,  by certain
authors may be omit, etc. I find no algorithm for identifying authors of
s 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] [html5] r6630 - [giow] (0) Define navigating to video and audio resources Fixing http://www.w3.o [...]

[Bjartur Thorlacius]

On Thu, 06 Oct 2011 17:56:23 -, Ian Hickson  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  but doesn't require or disallow extra features, such as
the zoom feature most brosers provide, we here just say to use ,
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] [html5] r6630 - [giow] (0) Define navigating to video and audio resources Fixing http://www.w3.o [...]

[Bjartur Thorlacius]

On Wed, 05 Oct 2011 17:37:22 -, Ian Hickson  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] Making selectionDirection platform-independent

[Bjartur Thorlacius]

On Mon, 26 Sep 2011 16:14:39 -, Philip Rogers  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

[Bjartur Thorlacius]

Should @placeholder be renamed @eg, and used exclusively for example input?

On Thu, Sep 22, 2011 at 11:53 PM, Bjartur Thorlacius
 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 . Should it not link to
> ?
>

[whatwg] The placeholder attribute

[Bjartur Thorlacius]

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 . Should it not link to  
?

Re: [whatwg] element

[Bjartur Thorlacius]

Þann fös  9.sep 2011 19:27, skrifaði Benjamin Hawkes-Lewis:

On Thu, Sep 8, 2011 at 4:58 PM, Bjartur Thorlacius  wrote:

Why use  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

[Bjartur Thorlacius]

Þ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] Proposal for improved handling of '#' inside of data URIs

[Bjartur Thorlacius]

Þ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

[Bjartur Thorlacius]

Þ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] element

[Bjartur Thorlacius]

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. Korpela  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 than
  when
we can use metadata, styling, and scripting? :-)).



Why use  when you have onclick and a settable document.location? :)

Re: [whatwg] add html-attribute for "responsive images"

[Bjartur Thorlacius]

> How exactly can I create a dynamic CMS website today with responsive images?
> I could manage my CSS file with my CMS which most of them don't support. I 
> could minify the CSS on the fly but in reality and from performance view it's 
> recommended to serve a static css file from a cookieless domain (which is 
> another than where my CMS is located). If I would use a CDN additionally how 
> should I change images on the fly? And, a client wants to change an image in 
> a WSIWYG editor not in a raw css file. We won't either as he can destroy the 
> entire stylesheet. I hope you now understand better what I mean.
But he won't edit "the entire stylesheet"; he'll create a new one.

Re: [whatwg] add html-attribute for "responsive images"

[Bjartur Thorlacius]

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 s or s 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  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]

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

[Bjartur Thorlacius]

Þ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

[Bjartur Thorlacius]

Þ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] implementation feedback

[Bjartur Thorlacius]

Þ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

[Bjartur Thorlacius]

Þ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  or , 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  and
 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. some 
text 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  and 
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

[Bjartur Thorlacius]

Þ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

[Bjartur Thorlacius]

On Sun, Aug 7, 2011 at 5:42 AM, Jukka K. Korpela  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  and friends.)
>
>> And perhaps
>>  standardized to mean indent.
>
> I wouldn't object to that, but _that_ would mean a change to the tradition
> of HTML specifications, and although  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  and
 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:  and  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

[Bjartur Thorlacius]

On 8/2/11, Ian Hickson  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

[Bjartur Thorlacius]

Þ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 , , , ,  and  be 
redefined to their HTML 3 typographical meanings. And perhaps 
 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  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 of,  and. 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 defining,  and  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 ,  and  to convey their defined meanings, even 
though some UAs might render all of them the same way.

Re: [whatwg] input element list attribute and filtering suggestions

[Bjartur Thorlacius]

Þann mán  1.ágú 2011 15:28, skrifaði Aryeh Gregor:
> On Fri, Jul 29, 2011 at 7:24 PM, Ian Hickson  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

[Bjartur Thorlacius]

Þann mán  1.ágú 2011 15:28, skrifaði Aryeh Gregor:

On Fri, Jul 29, 2011 at 7:24 PM, Ian Hickson  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] ... restrict reading value from JS?

[Bjartur Thorlacius]

Þ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] ... restrict reading value from JS?

[Bjartur Thorlacius]

On 7/11/11, Sean Connelly  wrote:
> As a web developer, if I wanted access to the password, I would then avoid
> using the  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  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
> , 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
> wrote:
>
>> On Sun, Jul 10, 2011 at 4:08 AM, Alex Vincent  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 ( downloads)

[Bjartur Thorlacius]

Þ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

[Bjartur Thorlacius]

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  through the DOM) so no new security concerns are 
introduced. The Growl binding might well be better by a new function, 
though.

Re: [whatwg] Custom protocol handlers

[Bjartur Thorlacius]

Þ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

[Bjartur Thorlacius]

Þ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)  or  element for use inside .

What about the common case of multiple quotations credited to the same 
source (interleaved with comments).

Re: [whatwg] a rel=attachment

[Bjartur Thorlacius]

Þ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 a, 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] a rel=attachment

[Bjartur Thorlacius]

Þann fös 15.júl 2011 18:39, skrifaði Jonas Sicking:

2011/7/14 Ian Fette (イアンフェッティ):
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] The blockquote element spec vs common quoting practices

[Bjartur Thorlacius]

On 7/15/11, Jukka K. Korpela  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  just like  (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.
>
 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  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 , 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  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  was implemented as , 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.  contains a human-readable name of a work. That'll
rarely be machine-readable.

Re: [whatwg] The blockquote element spec vs common quoting practices

[Bjartur Thorlacius]

On 7/15/11, Jukka K. Korpela  wrote:
> 14.07.2011 16:10, Bjartur Thorlacius wrote:
>> I don't think author names are allowed in  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] a rel=attachment

[Bjartur Thorlacius]

On 7/14/11, Karl Dubost  wrote:
> what about adding
>
> Save a Tree, Eat a beaver
>
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.

Afmæliskaka mín

Re: [whatwg] a rel=attachment

[Bjartur Thorlacius]

On 7/14/11, Ian Fette (イアンフェッティ)  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] The blockquote element spec vs common quoting practices

[Bjartur Thorlacius]

On 7/14/11, Kevin Marks  wrote:
> There is another common pattern, seen in blogging a lot, of putting
> the citation at the top eg
> As http://www.gyford.com/phil/";
> class="url" rel="acquaintance met colleague"> class="fn">Phil wrote about the  href="http://www.gyford.com/phil/writing/2009/04/28/geocities.php";>ugly
> and neglected fragments of Geocities:
>
> 
>   GeoCities 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
> period web vernacular. GeoCities sites show what normal,
> non-designer, people will create if given the tools available around
> the turn of the millennium.
> 
>
> (from jeremy) or pretty much any post here:
>
> http://www.theatlantic.com/ta-nehisi-coates/
>
> Would a  pattern in the blockquote work for this?
>
> If I was writing a detector for this pattern,  followed by a colon
> and   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] The blockquote element spec vs common quoting practices

[Bjartur Thorlacius]

Þann fim 14.júl 2011 11:09, skrifaði Jukka K. Korpela:

14.07.2011 13:49, Karl Dubost wrote:


Sur un pétale de lotus, j'écrivis ces quelques vers :
«Même si l'on vient me chercher
Comment, abandonnant la rosée
De pareil lotus,
Retournerai-je
Dans le monde changeant et frivole ? »
et j'envoyais ce pétale.

Shonagon, Sei,
Notes de chevet, p.64, Unesco, NRF, 1966.

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  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
Shōnagon, Sei be better?)

I don't think author names are allowed in  in HTML 5.

Re: [whatwg] The blockquote element spec vs common quoting practices

[Bjartur Thorlacius]

Þ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

[Bjartur Thorlacius]

Þ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
  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

Lorem ipsum

Bjartur
onthe second April, 1997


vs

Lorem ipsum



You've got two additional problems in your example:
* currently only the,  and  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 .



* 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 your  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  element would have to parsed just as 
date in a datetime attribute of a . 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 have  over
role="section" etc), and we already have three (I’d argue) perfectly
good elements for the data you are suggesting adding via attributes:
*  for following-line attribution and notes
*  for datetime information
*  and  for citation information

I've never heard this argument before. I thought we had  rather 
than  because the latter has a high 
noise-to-informa

Re: [whatwg] The blockquote element spec vs common quoting practices

[Bjartur Thorlacius]

On 7/8/11, Jeremy Keith  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 s 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 asdf 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

Lorem ipsum

Bjartur
on the second April, 1997


vs
cite="kennitala:2112952019">

Lorem ipsum

Re: [whatwg] ... restrict reading value from JS?

[Bjartur Thorlacius]

Þ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.  descendants of ). 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 
 
is optional.



Register a FooBar account

Username   




/**
  * 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] Call for Clarification of the Menu Element Et Al.

[Bjartur Thorlacius]

Þ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] The blockquote element spec vs common quoting practices

[Bjartur Thorlacius]

Þ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 , but just throwing everything 
inside of the  may very well be easier to implement. But is 
it really possible to mark such citations up without presentational 
elements?




Look ma, no 
!
I think we should keep citations outside of 
's 
contents as citations aren't part of the quote per se, but metadata on 
the quote and the quoted resource

Re: [whatwg] AppCache-related e-mails

[Bjartur Thorlacius]

Þann fim  7.júl 2011 05:30, skrifaði Felix Halim:

On Thu, Jul 7, 2011 at 3:57 AM, Karl Dubost  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

[Bjartur Thorlacius]

Þ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 every

Re: [whatwg] AppCache-related e-mails

[Bjartur Thorlacius]

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 be used for "extended paragraphs"?

[Bjartur Thorlacius]

On 6/14/11, Tab Atkins Jr.  wrote:
> On Tue, Jun 14, 2011 at 2:04 AM, Markus Ernst  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 "ok"s 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.


apples
pears
grapes

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

[Bjartur Thorlacius]

On 6/9/11, Mikko Rantalainen  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  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

[Bjartur Thorlacius]

On 3/11/11, Dave Kok  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

[Bjartur Thorlacius]

On 6/7/11, Mikko Rantalainen  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 tags

[Bjartur Thorlacius]

On 6/6/11, Boris Zbarsky  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 tags

[Bjartur Thorlacius]

On 6/5/11, Boris Zbarsky  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 tags

[Bjartur Thorlacius]

On 6/3/11, Boris Zbarsky  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 tags

[Bjartur Thorlacius]

On 6/3/11, Boris Zbarsky  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  element has a @title attribute already.
http://mysite.org/generate_progress_report.php?quarter=Q12010";
title="Progress report of Q1 2010">progress report

> 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 tags

[Bjartur Thorlacius]

On 5/26/11, Michal Zalewski  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

[Bjartur Thorlacius]

On 5/31/11, Felix Halim  wrote:
> On Mon, May 30, 2011 at 10:39 PM, Bjartur Thorlacius
>  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 (

Re: [whatwg] Unlimited pageStorage for App Cached web pages

[Bjartur Thorlacius]

Þ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

[Bjartur Thorlacius]

On 5/28/11, Felix Halim  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

[Bjartur Thorlacius]

On 5/16/11, Ian Hickson  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

[Bjartur Thorlacius]

On 5/6/11, Charles McCathieNevile  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

[Bjartur Thorlacius]

On 5/5/11, Charles McCathieNevile  wrote:
> On Thu, 05 May 2011 00:12:06 +0200, Bjartur Thorlacius
>  wrote:
>
>> On 5/3/11, Cameron Heavon-Jones  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] Small consistency issue with HTML5 nav element examples

[Bjartur Thorlacius]

On 5/4/11, Ian Hickson  wrote:
>> IMO browsers should implement .  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  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  should be used for creating hyperlinks that seem
to belong to head, in a tree of html>body>aside>a, 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 . 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] Proposal for a web application descriptor

[Bjartur Thorlacius]

On 5/3/11, Cameron Heavon-Jones  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] Indicate a file name for data: URLs?

[Bjartur Thorlacius]

On 3/21/11, Philip Jägenstedt  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] and links with @rel=embed

[Bjartur Thorlacius]

On 4/28/11, Ian Hickson  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
>>  support in wget, and a few other "non-mainstream" UAs.
>
> Well for  fallback people are likely to use  as well, but I
> don't think it makes sense to force every  to be a link.
Writing both  and  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.
Funny
cats jumping around.
Ok, this isn't valid CSS, but you get my thinking (I hope).