Re: [whatwg] Feedback on the Mozilla FullScreen API proposal
On Mon, Aug 9, 2010 at 5:58 PM, John Harding jhard...@google.com wrote: If there are multiple elements on the page (e.g. multiple inline video players) that could go fullscreen, you still need some way to determine which of them the user intended to make fullscreen. It's up to the script in the page to decide which element should be fullscreen. If scripts try to make different elements fullscreen at the same time, with the proposed spec, the most recent one to call requestFullscreen wins. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] input type=ink proposal
2010-06-08 19:26 EEST: Charles Pritchard: Has there been prior discussion about an input type=ink form element? This element would simply capture coordinates from a mouse (or touch/pen input device), allowing the user to reset the value of the element at their discretion. InkML is in last call: http://www.w3.org/TR/InkML/ Use Case: As part of a web form, a user signs their digital signature to confirm acceptance of terms. Uugh.. When I see digital signature or digitally signed, I expect public key decryption of cryptographic hash of the signed content, not a digitized image of one's signature. The former cannot be easily forged as opposed to the latter, which can be copied at will after receiving the first copy of digitized image for any purpose. In my opinion, WHATWG or W3C shouldn't provide any tools to make it any easier to create fake sense of security through digitized images. If you want digital signatures, do it correctly or don't do it at all! Use Case: While filling out an online profile, a user submits a simple doodle as their avatar. Has there ever been anybody asking for such a feature? If browsers supported capturing an image from a web camera, it would be much more sensible feature for this use case. Use Case: To quickly log into an online system, a user scribbles a password, which their server tests for fidelity to their prior scribbled input. I believe this is borderline sensible use case, but I think this should be interal user agent feature: use normal passwords for the login but use scribbled input for opening password keyring in the user agent (or operating system). In short, I don't agree that input type=ink should be supported. -- Mikko signature.asc Description: OpenPGP digital signature
Re: [whatwg] Please consider adding a couple more datetimeinput types - type=year and type=month-day
The VA's collections search uses a dropdown menu to select BC/AD on the date fields: http://collections.vam.ac.uk/ There is no standard way to do this so you'll find that each institution, with a searchable historical collection online, has probably implemented searching by year in its own fashion. I can see the value in agreeing on some standardised way of entering historical years into forms. Jim (National Maritime Museum/Royal Observatory Greenwich) Original Message: - The field being four digits long doesn't restrict its contents to four digits only. I suppose you do raise an interesting concern; should the year field also permit the entry of BC/AD? If so, that might invalidate the ability to use a number field; you'd need to use a validation pattern on a standard text field. �Kit On 09/08/2010, at 10:46 AM, Andy Mabbett wrote: On Mon, August 9, 2010 00:44, Kit Grose wrote: How is a year input any different from a four-digit input type=number field? Years can be more of fewer than four digits. Julius Caesar was born in 100 BC, for instance, while Manius Acilius Glabrio was consul in 91 AD. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk mail2web - Check your email from the web at http://link.mail2web.com/mail2web
Re: [whatwg] [br] element should not be a line break
Aryeh wrote: It's kind of a fake, though, since the definition includes spans of text whose typical typographic presentation is boldened and other prose whose typical typographic presentation is italicized. With those semantics, there's no sensible way to render them in any medium except bold and italics. In speech, you could never present them properly based on those semantics -- you'd probably just have to ignore them. For example, even if you wanted to audibly offset italicized thoughts (which you probably don't), you can't distinguish thoughts from ship names. According to the spec the i element represents a span of text in an alternate voice or mood. It's very easy to do that in speech but very hard in writing. That's why we have emoticons and irony tags. The new semantics are pretty solid for i. Admittedly, it's harder to make the case for the b element. b is closely tied to presentation. Its purpose is to stylistically offset something. Just like the mark element is used to highlight something in a different context, b is used to highlight something in the original context. In both cases leaving the highlighting out wouldn't change the meaning. b is an accessibility feature which makes it easier to identify key parts regardless of medium. I'd agree that b has the weakest semantics of all the semantic elements in the spec. Using spans with classes would work just as well. Aryeh wrote: The presentation-independence is hollow: the semantics are such that it is correct to use b/i for exactly those things that are conventionally bolded or italicized. You're implying that these things are conventionally bolded or italicized as an end in itself. Most of the time there's a reason why things are bolded or italicized other than I don't like regular type. The restricted set of means for conveying semantics in type-setting doesn't mean we can't use a richer set of elements in HTML. Even if at the end of the day all that richness is presented in bold and italics. Google doesn't care ;-)
Re: [whatwg] [br] element should not be a line break
Aryeh wrote: No, but it's a stand-in for a class of semantics that can only fairly be summarized as the places where you would always use a line break in print. There is no single behavior that screen readers could use to correctly present br, but the same is true for any number of other cases. You're right that screen readers cannot convey line breaks in a manner suitable to the medium. Line breaks do not exist in speech. They are specific to text presentation and even there they are a concession to the physical limits of paper, stone tablets etc. and to usability concerns. In a browser, line breaks are completely unnecessary. Even the longest paragraph could be just one line. Let the user scroll! That's why I originally suggested getting rid of the line break element. It is purely presentational and doesn't make sense in speech. However, we could use a break element on the text level. Breaks are natural to any medium. In speech they are represented as pauses or changes in voice/volume or beep. In print and on screen they are represented as white space or line breaks or separator lines or dots or whatever.
Re: [whatwg] [br] element should not be a line break
On Mon, 2010-08-09 at 11:55 +0200, Thomas Koetter wrote: Aryeh wrote: No, but it's a stand-in for a class of semantics that can only fairly be summarized as the places where you would always use a line break in print. There is no single behavior that screen readers could use to correctly present br, but the same is true for any number of other cases. You're right that screen readers cannot convey line breaks in a manner suitable to the medium. Line breaks do not exist in speech. They are specific to text presentation and even there they are a concession to the physical limits of paper, stone tablets etc. and to usability concerns. In a browser, line breaks are completely unnecessary. Even the longest paragraph could be just one line. Let the user scroll! That's why I originally suggested getting rid of the line break element. It is purely presentational and doesn't make sense in speech. However, we could use a break element on the text level. Breaks are natural to any medium. In speech they are represented as pauses or changes in voice/volume or beep. In print and on screen they are represented as white space or line breaks or separator lines or dots or whatever. I still think that they are more than presentational. Consider a poem being read out; the breaks are spoken with a pause (if that's the right way to say it?!) When you print the poem onto some visual media, the breaks are usually depicted with an actual line break, or sometimes a large space. I'm not entirely sure how a Braille browser would deal with a line break though, but I would assume there is some form of identifier for a new line/line break that might be used there. I don't see the br tag to be too different from something like em. There are ways to express this both visually and in speech that are totally different yet effective. Why are emphasised words written in italics anyway? It's only convention from the history of the printing press, not through any special symbolic link that we all have between the look and sound of the words. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Race condition in media load algorithm
On Fri, 06 Aug 2010 15:30:42 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
On 8/6/10 4:04 AM, Philip Jägenstedt wrote:
See, this concept of a script is a funny one, given that scripts are
reentrant, and that multiple different scripts can all be running at
the same time, possibly with event loops nested in between on the
conceptual callstack
Well, what we really look at is an execution thread. When a script
triggers a synchronous event handler or is otherwise suspended while
waiting for another thread to finish, we will wait for the outermost
suspended thread to finish executing. So, yeah, it's not completely
trivial :)
That really doesn't sound like it maps well to the proposed HTML5 spec,
for what it's worth... Of course it sounds like you're suggesting the
spec should be changed (without actually describing your changes in
speccable non-implementation-specific terms).
The await a stable state concept was introduced in
http://html5.org/tools/web-apps-tracker?from=3461to=3462 and is used
only for media elements. I can't remember any discussion about the change
in async behavior at the time, so didn't think much of it. It's because
Mozilla are implementing this now that the issue has surfaced, so let's
try to find a solution that's implementable in all browsers. Let's focus
on how this interacts with the parser, because that probably changes
everything else to fall into place, see below.
It's possible that it can't. It would depend on the exact steps that
run in the synchronous section, but since synchronous sections can't
trigger script it might not be detectable at all.
The most important things is that the following always alert 3
(NETWORK_NO_SOURCE):
!doctype html
video
source
scriptalert(document.querySelector('video').networkState)/script
In other words, the synchronous section must at the latest be run just
before running an inline script.
OK, let's focus on the issue at hand; I agree that we're more likely to
get somewhere with that than with generalities. What about this case:
script
var v = document.createElement(video);
var s = document.createElement(source);
v.appendChild(s);
document.body.appendChild(v);
alert(v.networkState);
/script
Should this also run the synchronous section before returning from the
appendChild call, even though there's a script active? If so, how does
that fit in with your proposal? If not, how is this different from your
example?
Whether it's the parser or a script that triggers the resource selection
algorithm, it is run up to step 2 where it's supposed to await a stable
state. Actually, my example is bad because networkState is set to
NETWORK_NO_SOURCE is step 1. What's actually interesting is when one can
see the side-effects of the synchronous section running, e.g. by
networkState being set to NETWORK_LOADING.
In the case of a script triggering it, it's important that the synchronous
section not be run until the script has finished modifying the DOM. If
that's accomplished by waiting until the thread has finished or by means
of the event loop isn't important as long as it's implementable and the
result is 100% predictable. Modulo the effects of modal dialogs and other
corner-cases, networkState should remain at NETWORK_NO_SOURCE for the
remainder of the script that triggered resource selection.
Parsing then. I don't know the parser section very well, but it doesn't
mention task, so I'm guessing that running it isn't considered a task
itself. I can't find anything to suggest that the parser inserting a
script element would cause synchronous sections to run before the script
is executed. What then, does await a stable state amount to? Just
running it the next time the event loop spins would appear to give rather
random results, right?
The parser example above alerts 0 or 3 depending on whether the sync
section has run. Opera alerts 3, as the sync section is run at the same
time the source element is inserted by the parser. If that's not the right
thing to do, what is?
--
Philip Jägenstedt
Core Developer
Opera Software
Re: [whatwg] [br] element should not be a line break
Aryeh wrote: It cannot be used if you don't want to include the words like Street:, which are typically omitted, unless you add the dts with display: none, which is unreasonable. Aryeh wrote: Every group must have a dt element. As Tab already pointed out, I quoted the error-recovery behavior. You were right that dl elements shouldn't be used without a dt element. So, an address could be marked up like this: address class=vcard dl class=adr dt class=fnP. Sherman/dt dd class=street-address42 Wallaby Way/dd dd class=localitySydney/dd /dl /address Doing the same with explicit line breaks is awkward if you want to use microformats. address class=vcard p class=adr span class=fnP. Sherman/spanbr span class=street-address42 Wallaby Way/spanbr span class=localitySydney/span /p /address But I'm sure somebody can explain to me why line breaks must be part of the address. Aryeh wrote: No elements do. Characters do, though. Every period, comma, semicolon, colon, and dash is a minor logical break in the paragraph, but it would be incorrect to use br for any of those. Yes, even the space character breaks up a run of characters into words. My point is not that there are no other kinds of breaks. What I'm saying is that there's a somewhat stronger text-level break. Something that falls between character-type breaks and paragraph breaks. That something is used in poems and it can be used to split up an address. But in my opinion, that's definitely not a *line* break. Otherwise, a poem couldn't really be read aloud. Aryeh wrote: So can omitting line breaks. The address 123 Imaginary Place New York, NY 12345 is not the same as 123 Imaginary Place New York, NY 12345 Absolutely! But are these different addresses? 123 Imaginary Place New York, NY 12345 123 Imaginary Place | New York, NY 12345 123 Imaginary Place * New York, NY 12345 Street number: 123 Street: Imaginary Place City: New York State: NY Zip code: 12345 I would say no. Even though the first three don't contain a line break while the last one contains three additional line breaks. How can a *line* break then be part of the content? Aryeh wrote: Indeed, the spec explicitly forbids using br where the line break is presentational: br elements must be used only for line breaks that are actually part of the content, as in poems or addresses. Now you're quoting the part of the spec that I say is wrong to prove me wrong. That's not fair! Just eliminate the word line in the spec and everything is fine.
Re: [whatwg] Fwd: Discussing WebSRT and alternatives/improvements
On Sat, 07 Aug 2010 09:57:39 +0200, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
Hi Philip,
On Sat, Aug 7, 2010 at 1:50 AM, Philip Jägenstedt phil...@opera.com
wrote:
* there is a possibility to provide script that just affects the
time-synchronized text resource
I agree that some metadata would be useful, more on that below. I'm not
sure why we would want to run scripts inside the text document, though,
when
that can be accomplished by using the TimedTrack API from the containing
page.
Scripts inside a timed text document would only be useful for
applications
that use the track not in conjunction with a Web page.
Do you mean that media players could include a JavaScript engine just for
supporting scripts in WebSRT? Not to say that it can't happen, but it
seems a bit unlikely.
2. There is a natural mapping of WebSRT into in-band text tracks.
Each cue naturally maps into a encoding page (just like a WMML cue
does,
too). But in WebSRT, because the setup information is not brought in a
hierarchical element surrounding all cues, it is easier to just chuck
anything that comes before the first cue into an encoding header page.
For
WMML, this problem can be solved, but it is less natural.
I really like the idea of letting everything before the first timestamp
in
WebSRT be interpreted as the header. I'd want to use it like this:
# author: Fan Subber
# voices: 1 Boy
# 2 Girl
01:23:45.678 -- 01:23:46.789
1 Hello
01:23:48.910 -- 01:23:49.101
2 Hello
It's not critical that the format of the header be machine-readable,
but we
could of course make up a key-value syntax, use JSON, or something else.
I disagree. I think it's absolutely necessary that the format of the
header
be machine-readable. Just like EXIF in images is machine readable or ID3
in
MP3 is machine-readable. It would be counter-productive not to have it
machine-readable, in particular useless to archiving and media management
solutions.
OK, so maybe key-values?
Author: Fan Subber
Voice: 1 Boy
Voice: 2 Girl
01:23:45.678 -- 01:23:46.789
1 Hello
This looks a bit like HTTP headers. (I'm not sure I'd actually want to
allow multiple occurrences of the same key, in practice that seems to
result in inconsistencies in how people mark up multiple authors.)
I'm not sure of the best solution. I'd quite like the ability to use
arbitrary voices, e.g. to use the names/initials of the speaker rather
than
a number, or to use e.g. shouting in combination with CSS :before {
content 'Shouting: ' } or similar to adapt the display for different
audiences (accessibility, basically).
I agree. I think we can go back to usingspan and @class and @id and
that
would solve it all.
I guess this is in support of Henri's proposal of parsing the cue using
the HTML fragment parser (same as innerHTML)? That would be easy to
implement, but how do we then mark up speakers? Using span
class=narrator/span around each cue is very verbose. HTML isn't very
good for marking up dialog, which is quite a limitation when dealing with
subtitles...
* there is no language specification for a WebSRT resource; while this
will
not be a problem when used in conjunction with a track element, it
still
is a problem when the resource is used just by itself, in particular
as a
hint for font selection and speech synthesis.
The language inside the WebSRT file wouldn't end up being used for
anything
by a browser, as it needs to know the language before downloading it to
know
whether or not to download it at all. Still, I'd like a header section
in
WebSRT. I think the parser is already defined so that it would ignore
garbage before the first cue, so this is more a matter of making it
legal
syntax.
Not quite. Some metadata in the header can make sense to also expose to
the
Web page.
I agree that we need a structured header section in WebSRT.
Fair enough, we should revisit this when deciding on how to expose
metadata in media resources in general.
* there is no means to identify which parser is required in the cues
(is
it
plain text, minimal markup, or anything?) and therefore it is not
possible for an application to know how it should parse the cues.
All the types that are actually for visual rendering are parsed in the
same
way, aren't they? Of course there's no way for non-browsers to know that
metadata tracks aren't interesting to look at as subtitles, but I think
showing the user the garbage is a quicker to communicate that the file
isn't
for direct viewing than hiding the text or similar.
The spec says that files of kind descriptions and metadata are not
displayed. It seems though that the parsing section will try two
interfaces:
HTML and plain. I think there is a disconnect there. If we already know
that
it's not parsable in HTML, why even try?
I was confused. The parsing algorithm does the same thing regardless of
what kind of text track it is
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
Le 09/08/10 03:11, Kit Grose a écrit : should the year field also permit the entry of BC/AD? Or a jewish year? Or a muslim year? Or counting since the first tooth of Carolus Magnus or the last onomatopoeia pronounced by Hannibal during his crossing of the Alps? Tantek needs a year. He never said he needs to specify in which system the year is counted. He never said he cannot use a radiobutton for BC/AD or any other calendaring system aside of the year input. Why make things complex when it's possible to make them simple? /Daniel
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
On Aug 8, 2010, at 9:49 PM, Jonathan Castello wrote: On Sun, Aug 8, 2010 at 6:42 PM, Andy Mabbett a...@pigsonthewing.org.uk wrote: On Mon, August 9, 2010 02:19, Ben Schwarz wrote: While creating an input that works for every use case you can think of sounds like a good idea, I'd like to question weather a user would ever *enter a date* that would require the inclusion of BC/AD. I'm certain that there is a requirement to markup such text, but as for * entry* I'm strongly of the opinion that you're over cooking this. It took only seconds to find: http://www.guernsey.net/~sgibbs/roman.html which requires (for some dates) entry of 1, 2, and 3-figure and BC years. Likewise: http://www.smart.net/~mmontes/ec-cal.html Please enter a year after A.D. 325 Consider also a site allowing a search of an archive of archaeological finds by year of origin. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk Couldn't the BC/AD case be handled intuitively by a dropdown right next to the year field that contains those two options? I do not think that there is an easy solution for this and other dating issues. This field is extraordinarily complex, with lots of corner cases, some very erudite in nature. Note, for example, that there are three conventions in our calendar system for handling early dates - the BC/BCE one (where there is no year zero, and so 1 AD is preceded by 1 BC, and there are 9 years between 5 BC and 5 AD), a smoothly running one WITH a year zero (with 10 years between -5 and +5), and the Before Present one (where 1950 AD/CE is the reference epoch, i.e., the year zero). Radiocarbon dates are almost always Before Present (i.e., before 60 years in the past). When I was worrying about this sort of thing as an astronomer, I felt that the only really trustworthy way to describe dates were Julian Days, and I don't think you are going to make HTML5 run on Julian Days. (There is, of course, also the ISO 8601 standard on describing dates, which I don't think is going to help either - see http://en.wikipedia.org/wiki/ISO_8601) What I would recommend is, in addition to the datetime input types, an optional type=Calendar (e.g., type=Gregorian), which could be ignored or used, as the circumstances required. Regards Marshall -- ~Jonathan Castello P.S. I'm new to the list, don't kill me!
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
On Mon, August 9, 2010 15:10, Daniel Glazman wrote: Le 09/08/10 03:11, Kit Grose a écrit : should the year field also permit the entry of BC/AD? Or a jewish year? Or a muslim year? Or counting since the first tooth of Carolus Magnus or the last onomatopoeia pronounced by Hannibal during his crossing of the Alps? Do you see anyone suggesting such things? If not, please can we avid such hyperbole. Tantek needs a year. He never said he needs to specify in which system the year is counted. He never said he cannot use a radiobutton for BC/AD or any other calendaring system aside of the year input. We (not just one person) always need to be able to know the calendar system in use; it's just that the default is Gregorian. Discussions of preference for one kind of UI over another are premature. Why make things complex when it's possible to make them simple? Why make things /overly/ simple, if it prevents valid use cases from being realised? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
On Mon, August 9, 2010 16:03, Marshall Eubanks wrote: I do not think that there is an easy solution for this and other dating issues. This field is extraordinarily complex, with lots of corner cases, some very erudite in nature. Indeed; but there are sufficient pre-Gregorian dates in use on the web to warrant at least /one/ method of publishing them. [...] What I would recommend is, in addition to the datetime input types, an optional type=Calendar (e.g., type=Gregorian), which could be ignored or used, as the circumstances required. That is the current suggestion; reusing the parameter name CALTYPE from vCard. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
[whatwg] video await a stable state in resource selection (Was: Race condition in media load algorithm)
This goes quite a bit from the original topic, so renaming accordingly.
The issue at hand is the await a stable state concept in the resource
selection algorithm:
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-algorithm
On Mon, 09 Aug 2010 14:16:04 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
On 8/9/10 6:28 AM, Philip Jägenstedt wrote:
Let's focus on how this interacts with the parser, because that probably
changes everything else to fall into place, see below.
OK.
In the case of a script triggering it, it's important that the
synchronous section not be run until the script has finished modifying
the DOM.
Why? Maybe if I understood what we're trying to accomplish with the
synchronous section bit here I'd have a better idea of how it should
work...
The general idea of waiting is that since the following steps of the
resource selection algorithm inspects video elements src attribute and
source element children, those should be in a consistent state before the
checking is done. In particular, if a script is removing and inserting
source elements, then after any given modification the DOM might not be in
a state where the right source will be selected. For example:
body
script
var v = document.createElement('video');
var exts=[webm, mp4];
exts.forEach(function(ext) {
var s = document.createElement('source');
v.appendChild(s);
s.src = foo.+ext;
s.type = video/+ext;
document.body.appendChild(v);
});
/script
Unless we wait until the script has finished before running the
synchronous section, no source at all will be selected, because at the
point when the source element is inserted it doesn't have src and type
set. However, as long as the same is true in all browsers this seems easy
to fix in the script itself, just a bit non-obvious.
I'm trying to come up with a big scary problem that would motivate the
complexity of await a stable state, but I can't see it. I doubt
StackOverflow would be flooded by issues caused by quirks as the one
above. The parts of the algorithm that actually need to be run
asynchronously is calling resource fetch (since that waits for the
network) and step 21, as that waits for either the parser or a script to
insert a source element and can wait forever.
So, what I'm tentatively suggesting is:
1. Remove the await a stable state concept and just continue running the
steps that follow it. (This is what Opera does now when resource selection
is triggered by the parser, as I have no idea how long to wait otherwise.)
2. Instead of calling the resource fetch algorithm in step 5/9, queue a
task to call it and then return. The failure steps that follow can be
called explicitly from the resource fetch algorithm.
3. In step 21, instead of waiting forever, just return and let inserting a
source element cause it to continue at step 22.
Since this doesn't introduce any new concepts to the spec, I assume it
would be implementable in Gecko?
--
Philip Jägenstedt
Core Developer
Opera Software
Re: [whatwg] video await a stable state in resource selection (Was: Race condition in media load algorithm)
On 8/9/10 12:14 PM, Philip Jägenstedt wrote:
Why? Maybe if I understood what we're trying to accomplish with the
synchronous section bit here I'd have a better idea of how it should
work...
The general idea of waiting is that since the following steps of the
resource selection algorithm inspects video elements src attribute and
source element children, those should be in a consistent state before
the checking is done.
OK, but then why are we not imposing such a requirement for the case
when the video is being created by the parser?
body
script
var v = document.createElement('video');
var exts=[webm, mp4];
exts.forEach(function(ext) {
var s = document.createElement('source');
v.appendChild(s);
s.src = foo.+ext;
s.type = video/+ext;
document.body.appendChild(v);
});
/script
Unless we wait until the script has finished before running the
synchronous section, no source at all will be selected
Because changes to the set of source elements do not restart the
resource selection algorithm, right? Why don't they, exactly? That
seems broken to me, from the POV of how the rest of the DOM generally
works (except as required by backward compatibility considerations)...
However, as long as the same is true in all browsers this seems
easy to fix in the script itself, just a bit non-obvious.
But why are we purposefully introducing hysteresis into the DOM? It'd
make a lot more sense to me to not have hysteresis here if at all possible.
I'm trying to come up with a big scary problem that would motivate the
complexity of await a stable state, but I can't see it. I doubt
StackOverflow would be flooded by issues caused by quirks as the one
above.
It actually probably would, if if we actually had such a quirk.
1. Remove the await a stable state concept and just continue running
the steps that follow it. (This is what Opera does now when resource
selection is triggered by the parser, as I have no idea how long to wait
otherwise.)
I have a really hard time believing that you trigger resource selection
when the video is inserted into the document and don't retrigger it
afterward, given that... do you?
2. Instead of calling the resource fetch algorithm in step 5/9
There doesn't seem to be such a step...
3. In step 21, instead of waiting forever, just return and let inserting
a source element cause it to continue at step 22.
Again, the numbering seems to be off.
Since this doesn't introduce any new concepts to the spec, I assume it
would be implementable in Gecko?
Given the premise, presumably. But the resulting behavior still seems
broken in the parser case; see above
-Boris
Re: [whatwg] HTML resource packages
On Mon, Aug 9, 2010 at 9:47 AM, Aryeh Gregor simetrical+...@gmail.com wrote: If UAs can assume that files with the same path are the same regardless of whether they came from a resource package or which, and they have all but a couple of the files cached, they could request those directly instead of from the resource package, even if a resource package is specified. These kinds of heuristics are far beyond the scope of resource packages as we're planning to implement them. Again, I think this type of behavior is the domain of a large change to the networking stack, such as SPDY, not a small hack like resource packages. -Justin On Mon, Aug 9, 2010 at 9:47 AM, Aryeh Gregor simetrical+...@gmail.com wrote: On Fri, Aug 6, 2010 at 7:40 PM, Justin Lebar justin.le...@gmail.com wrote: I think this is a fair point. But I'd suggest we consider the following: * It might be confusing for resources from a resource package to show up on a page which doesn't opt-in to resource packages in general or to that specific resource package. Only if the resource package contains a different file from the real one. I suggest we treat this as a pathological case and accept that it will be broken and confusing -- or at least we consider how many extra optimizations we could make if we did accept that, before deciding whether the extra performance is worth the confusion. * There's no easy way to opt out of this behavior. That is, if I explicitly *don't* want to load content cached from a resource package, I have to name that content differently. Why would you want that, if the files are the same anyway? * The avatars-on-a-forum use case is less convincing the more I think about it. Certainly you'd want each page which displays many avatars to package up all the avatars into a single package. So you wouldn't benefit from the suggested caching changes on those pages. I don't see why not. If UAs can assume that files with the same path are the same regardless of whether they came from a resource package or which, and they have all but a couple of the files cached, they could request those directly instead of from the resource package, even if a resource package is specified. So if twenty different people post on the page, and you've been browsing for a while and have eighteen of their avatars (this will be common, a handful of people tend to account for most posts in a given forum): 1) With no resource packages, you fetch two separate avatars (but on earlier page views you suffered). 2) With resource packages as you suggest, you fetch a whole resource package, 90% of which you don't need. In fact, you have to fetch a resource package even if you have 100% of the avatars on the page! No two pages will be likely to have the same resource package, so you can't share cache at all. 3) With resource packages as I suggest, you fetch only two separate avatars, *and* you got the benefits of resource packages on earlier pages. The UA gets to guess whether using resource packages would be a win on a case-by-case basis, so in particular, it should be able to perform strictly better than either (1) or (2), given decent heuristics. E.g., the heuristic fetch the resource package if I need at least two files, fetch the file if I only need one will perform better than either (1) or (2) in any reasonable circumstance. I think this sort of situation will be fairly common. Has anyone looked at a bunch of different types of web pages and done a breakdown of how many assets they have, and how they're reused across pages? If we're talking about assets that are used only on one page (image search) or all pages (logos, shared scripts), your approach works fine, but not if they're used on a random mix of pages. I think a lot of files will wind up being used on only particular subsets of pages. In general, I think we need something like SPDY to really address the problem of duplicated downloads. I don't think resource packages can fix it with any caching policy. Certainly there are limits to what resource packages can do, but we can wind up closer to the limits or farther from them depending on the implementation details.
[whatwg] select required
I just read Hixie's message here:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-November/017583.html
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-November/017583.htmlWhile
I understand the reasoning for not implementing a bunch of new attributes
and functionality, I would still like to see select required even without
the other suggestions as requiring at least one option element to be
successful with a non-empty value.
I was beginning to write a form for a site and I thought I'd go ahead and
use input required and textarea required with some css:
[required] ~ label:after { content: '*' }
... and possibly javascript to read that attribute, etc.
But since I can't implement that on my select elements and still validate,
I plan to skip the required attribute entirely and use class names instead
for now so that all the form elements are consistent.
--
Jon Barnett
Re: [whatwg] Problems with the Atom Conversion algorithm.
On Fri, 11 Jun 2010, Tab Atkins Jr. wrote: 1. The HTML algo puts the url for atom:link elements in the content of the link. It should be in the @href of the link. Fixed. 3. The HTML algo sets the @type attribute on atom:content to xml in some circumstances. It should be xhtml. Fixed. 4. The HTML algo should include an xml:base element in the produced feed so that relative links work correctly. Done. (Note: there's no such thing as an xml:base element, it's an attribute.) 5. I'm not 100% certain on this one, but I think that, in the current step 15.8 of the HTML algo, it should produce a div element in the XHTML namespace. As far as I can tell, it does. The algo currently doesn't specify a namespace for the element. Which element? On Fri, 11 Jun 2010, Edward O'Connor wrote: 2. The title of atom entries is constrained to contain text only, That's not quite right. atom:title is an Atom Text Construct, which, despite having the word 'text' in its name, can contain all sorts of things. atom:title is the same as atom:summary, atom:content, and atom:rights, so the algo should handle it in the same way as it does atom:content. Fixed, I think. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] getSelection() in a display:none iframe
http://www.whatwg.org/specs/web-apps/current-work/#dom-getselection Gecko returns null for a display:none iframe, but returns an empty Selection object for a visible iframe with no selection. As best I can tell, WebKit and Opera return a selection in both cases. I don't feel strongly about which behavior is correct, but the spec should deal with this case. On the one hand, the Gecko behavior makes sense because you can't have a selection in a display:none frame, so the methods to set a selection would fail. On the other hand, you can get into a similar situation by getting a Selection and then making the iframe display:none, so that case needs to be dealt with either way. Relevant bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=585229 https://bugs.webkit.org/show_bug.cgi?id=43655 Ojan
Re: [whatwg] HTML resource packages
Can you provide the content of the page which you used in your whitepaper? (https://bug529208.bugzilla.mozilla.org/attachment.cgi?id=455820) I'll post this to the bug when I get home tonight. But your comments are astute -- the page I used is a pretty bad benchmark for a variety of reasons. It sounds like you probably could hack up a much better one. a) Looks like pages were loaded exactly once, as per your notes? How hard is it to run the tests long enough to get to a 95% confidence interval? Since I was running on a simulated network with no random parameters (e.g. no packet loss), there was very little variance in load time across runs. d) What did you do about subdomains in the test? I assume your test loaded from one subdomain? That's correct. I'm betting time-to-paint goes through the roof with resource bundles:-) It does right now because we don't support incremental extraction, which is why I didn't bother measuring time-to-paint. The hope is that with incremental extraction, we won't take too much of a hit. -Justin On Mon, Aug 9, 2010 at 1:30 PM, Mike Belshe m...@belshe.com wrote: Justin - Can you provide the content of the page which you used in your whitepaper? (https://bug529208.bugzilla.mozilla.org/attachment.cgi?id=455820) I have a few concerns about the benchmark: a) Looks like pages were loaded exactly once, as per your notes? How hard is it to run the tests long enough to get to a 95% confidence interval? b) As you note in the report, slow start will kill you. I've verified this so many times it makes me sick. If you try more combinations, I believe you'll see this. c) The 1.3MB of subresources in a single bundle seems unrealistic to me. On one hand you say that its similar to CNN, but note that CNN has JS/CSS/images, not just thumbnails like your test. Further, note that CNN pulls these resources from multiple domains; combining them into one domain may work, but certainly makes the test content very different from CNN. So the claim that it is somehow representative seems incorrect. For more accurate data on what websites look like, see http://code.google.com/speed/articles/web-metrics.html d) What did you do about subdomains in the test? I assume your test loaded from one subdomain? e) There is more to a browser than page-load-time. Time-to-first-paint is critical as well. For instance, in WebKit and Chrome, we have specific heuristics which optimize for time-to-render instead of total page load. CNN is always cited as a bad page, but it's really not - it just has a lot of content, both below and above the fold. When the user can interact with the page successfully, the user is happy. In other words, I know I can make webkit's PLT much faster by removing a couple of throttles. But I also know that doing so worsens the user experience by delaying the time to first paint. So - is it possible to measure both times? I'm betting time-to-paint goes through the roof with resource bundles:-) If you provide the content, I'll try to run some tests. It will take a few days. Mike On Mon, Aug 9, 2010 at 9:52 AM, Justin Lebar justin.le...@gmail.com wrote: On Mon, Aug 9, 2010 at 9:47 AM, Aryeh Gregor simetrical+...@gmail.com wrote: If UAs can assume that files with the same path are the same regardless of whether they came from a resource package or which, and they have all but a couple of the files cached, they could request those directly instead of from the resource package, even if a resource package is specified. These kinds of heuristics are far beyond the scope of resource packages as we're planning to implement them. Again, I think this type of behavior is the domain of a large change to the networking stack, such as SPDY, not a small hack like resource packages. -Justin On Mon, Aug 9, 2010 at 9:47 AM, Aryeh Gregor simetrical+...@gmail.com wrote: On Fri, Aug 6, 2010 at 7:40 PM, Justin Lebar justin.le...@gmail.com wrote: I think this is a fair point. But I'd suggest we consider the following: * It might be confusing for resources from a resource package to show up on a page which doesn't opt-in to resource packages in general or to that specific resource package. Only if the resource package contains a different file from the real one. I suggest we treat this as a pathological case and accept that it will be broken and confusing -- or at least we consider how many extra optimizations we could make if we did accept that, before deciding whether the extra performance is worth the confusion. * There's no easy way to opt out of this behavior. That is, if I explicitly *don't* want to load content cached from a resource package, I have to name that content differently. Why would you want that, if the files are the same anyway? * The avatars-on-a-forum use case is less convincing the more I think about it. Certainly you'd want each page
Re: [whatwg] getSelection() in a display:none iframe
On 8/9/10 4:23 PM, Ojan Vafai wrote: On the one hand, the Gecko behavior makes sense because you can't have a selection in a display:none frame, so the methods to set a selection would fail. On the other hand, you can get into a similar situation by getting a Selection and then making the iframe display:none, so that case needs to be dealt with either way. Note that in Gecko the selection which has outlived its presentation is totally unusable. Even if the document gets a new presentation the selection is not attached to that presentation. -Boris
Re: [whatwg] HTML resource packages
On 8/9/10 4:30 PM, Mike Belshe wrote: CNN is always cited as a bad page, but it's really not - it just has a lot of content, both below and above the fold. It's a bad page because 1) It sends hundreds of kilobytes of content for no obvious reason whatsoever; most of it is unused and 2) it sends said content with no gzip compression. -Boris
Re: [whatwg] Proposal for a widget tag
On Sun, 13 Jun 2010, Schalk Neethling wrote: I have watched one video after the other, and read articles just the same. I know we are all unsure when to use section and when to use article. But marking up something as simple as a blogroll as an article? This really makes no semantic sense to me. Therefore I suggest the addition of the widget tag. Below is the most obvious use case and makes much more sense to me. Thoughts? section widget id=blogroll /widget widget id=search /widget /section What's wrong with: section section id=blogroll /section section id=search /section /section ...? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Please consider impedance matching time and datetime input types
Summary: HTML5 provides mechanisms for both semantically inputting datetime values (via the 6 new datetime input types), and semantically outputting datetime values (via the new time element). However, the types/granularities of dates and times that are supported do not match up on input vs output, and they should. input type=date - time-MM-DD/time input type=datetime - time-MM-DDTHH:MM:SS/time input type=month - not supported in current time element input type=week - not supported in current time element input type=time - timeHH:MM:SS/time input type=datetime-local - timeHH:MM:SS-ZZ:YY/time New proposed input elements: input type=year - not supported in current time element input type=month-day - not supported in current time element From a design, learning/teaching perspective, it is much better if they are made to match up, that is if every type/granularity of datetime that can be entered can also be semantically marked up (and vice versa). Thus, please consider impedance matching time and datetime input types. More details, use-cases, research here: http://wiki.whatwg.org/wiki/Time_element#impedance_match_new_date_time_inputs and related proposals: * http://wiki.whatwg.org/wiki/Time_element#year_only * http://wiki.whatwg.org/wiki/Time_element#year_month_only * http://wiki.whatwg.org/wiki/Time_element#year_week_only * http://wiki.whatwg.org/wiki/Time_element#month_day_only I encourage fellow web authors and browser implementers to add their opinions/comments to those wiki page sections. Thanks! Tantek Related thread fragments from previous thread on new datetime inputs (type=year, type=month-day) : On Sun, Aug 8, 2010 at 6:19 PM, Ben Schwarz ben.schw...@gmail.com wrote: While creating an input that works for every use case you can think of sounds like a good idea, I'd like to question weather a user would ever enter a date that would require the inclusion of BC/AD. ... I'm certain that there is a requirement to markup such text, It would be great if you could add your +1 accordingly to allowing time to markup just a year: http://wiki.whatwg.org/wiki/Time#year_only but as for entry I'm strongly of the opinion that you're over cooking this. That may be. My goal with these 2 additional datetime inputs (to the current 6, thus making 8 total) was to not to be comprehensive but to fill out what seemed to be a relatively similar set of datetime inputs in terms of frequency of actual use cases. On Sun, Aug 8, 2010 at 7:20 PM, Ben Schwarz ben.schw...@gmail.com wrote: ... Given that one of the principals of HTML5 is to have a well designed product that is easily understandable, I'd prefer to follow the path of simplistic, minimal design. Ben, I tend to agree with those design principles. In this case the only reason I proposed those two additional input types (year, month-day) is that they seem to naturally fit in with the existing 6 (month, week, date, datetime, datetime-local, time) and in seem just as practically useful, if not more so, e.g. I see a lot more obvious use-cases for the new input type=year as compared to the existing input type=week for example. Not one where every example found will be implemented—I'd like to think that a browser vendor would find it very difficult to schedule the time to implement such a full featured method of handling every date representation known to man, rather than other awesome feature x. Of course, and I tend to agree with your general analysis/reasoning. Frankly, doing a good job on the existing 6 datetime inputs in general is quite challenging/difficult, even with the progress/designs that Opera and Safari have put forth. However, from a design (visual, interactive) perspective, the 6 existing datetime inputs cover a sufficient diversity of cases that if/when you (e.g. a browser implementer) do implement them, it's pretty obvious/easy how to implement the 2 additional ones I've proposed as variants. I deliberately proposed adding input type=year and input type=month-day both because of their utility/use-cases and *specifically* because the marginal implementation cost of adding them to the existing 6 is quite small in comparison to the marginal benefit of said use-cases. On Mon, Aug 9, 2010 at 7:10 AM, Daniel Glazman daniel.glaz...@disruptive-innovations.com wrote: Tantek needs a year. He never said he needs to specify in which system the year is counted. He never said he cannot use a radiobutton for BC/AD or any other calendaring system aside of the year input. Why make things complex when it's possible to make them simple? Right, I am ok with simply incrementally adding input type=year and type=month-day within existing calendar/datetime constraints (Gregorian assumption etc.) I believe the existing documented use-cases justify this small addition. Whether or not we explore additional calendaring systems (and their use-cases) is perhaps
Re: [whatwg] Don't throw for HTMLInputElement.files
On Tue, 15 Jun 2010, Jonas Sicking wrote: Currently HTMLInputElement.files throws if accessed when type != file. I think it would be better to return null or an empty list. We generally try to avoid throwing in general, and in particular things like HTMLInputElement.checked doesn't throw even if the value doesn't apply. So for consistency I don't think HTMLInputElement.files should throw either. Another reason not to throw is that people every so often enumerate all the IDL attributes of element using |for each| constructs in javascript. Such code tends to break if there are properties that throw upon access. Changed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] idea about html code security anti xss
On Wed, 16 Jun 2010, gabme...@westweb.at wrote: I had just this idea after reading so much about xss and code injection. I think there is a simple solution: 1.) I now invent an attribute called strlen= I append this to a div strlen=94843htmlcode with strlen of 94843 bytes including whitespace/div The browser know knows the exact position where the divtag must end. You cannot inject some code that closes the tag before. 2.) you can now control the code inside the div. you can also append a second attribute called secure that prevents any scriptcode to run from inside the div. On Wed, 16 Jun 2010, Anne van Kesteren wrote: We considered something like this before, but it was thought to be too complicated and not backwards compatible enough. In the current draft you will find iframe srcdoc=.../iframe which does what you propose with the relatively small change that the sandboxed code is inside an attribute rather than an element. For fallback the src attribute can be used. Indeed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] HTML5 video source dimensions and bitrate
Hello! I'm working on some bandwidth switching logic for the JW Player for HTML5. The way that we've implemented our bandwidth switching logic relies on knowing both the dimensions of the video as well as it's bitrate (for more info on the logic, see our dynamic streaming documentation [1]). MRSS supports this quite nicely, as their media content elements allow for width, height, and bitrate, per our example [2]. As a result, I was wondering if there's some way to attach metadata like the dimensions and bitrate to source elements of HTMLMediaElements in the DOM. I realize that we could wait for metadata to arrive for each source, but it would be nice if it was possible to make an intelligent choice before attempting to play all of them. Best, Zach [1] : http://www.longtailvideo.com/support/jw-player/jw-player-for-flash-v4/12208/video-delivery-rtmp-streaming#dynamicstreaming [2] : http://developer.longtailvideo.com/player/testing/files/bitrates.xml -- Zachary Ozer Developer, LongTail Video w: longtailvideo.com • e: z...@longtailvideo.com • p: 212.244.0140 • f: 212.656.1335 JW Player | Bits on the Run | AdSolution
Re: [whatwg] Fwd: Discussing WebSRT and alternatives/improvements
On Tue, Aug 10, 2010 at 12:04 AM, Philip Jägenstedt phil...@opera.comwrote:
On Sat, 07 Aug 2010 09:57:39 +0200, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
Hi Philip,
On Sat, Aug 7, 2010 at 1:50 AM, Philip Jägenstedt phil...@opera.com
wrote:
* there is a possibility to provide script that just affects the
time-synchronized text resource
I agree that some metadata would be useful, more on that below. I'm not
sure why we would want to run scripts inside the text document, though,
when
that can be accomplished by using the TimedTrack API from the containing
page.
Scripts inside a timed text document would only be useful for applications
that use the track not in conjunction with a Web page.
Do you mean that media players could include a JavaScript engine just for
supporting scripts in WebSRT? Not to say that it can't happen, but it seems
a bit unlikely.
Yes, it's indeed an out there feature and I am not worried about having it
now. I just mentioned it as a simple possibility for extension.
2. There is a natural mapping of WebSRT into in-band text tracks.
Each cue naturally maps into a encoding page (just like a WMML cue does,
too). But in WebSRT, because the setup information is not brought in a
hierarchical element surrounding all cues, it is easier to just chuck
anything that comes before the first cue into an encoding header page.
For
WMML, this problem can be solved, but it is less natural.
I really like the idea of letting everything before the first timestamp
in
WebSRT be interpreted as the header. I'd want to use it like this:
# author: Fan Subber
# voices: 1 Boy
# 2 Girl
01:23:45.678 -- 01:23:46.789
1 Hello
01:23:48.910 -- 01:23:49.101
2 Hello
It's not critical that the format of the header be machine-readable, but
we
could of course make up a key-value syntax, use JSON, or something else.
I disagree. I think it's absolutely necessary that the format of the
header
be machine-readable. Just like EXIF in images is machine readable or ID3
in
MP3 is machine-readable. It would be counter-productive not to have it
machine-readable, in particular useless to archiving and media management
solutions.
OK, so maybe key-values?
Author: Fan Subber
Voice: 1 Boy
Voice: 2 Girl
01:23:45.678 -- 01:23:46.789
1 Hello
This looks a bit like HTTP headers. (I'm not sure I'd actually want to
allow multiple occurrences of the same key, in practice that seems to result
in inconsistencies in how people mark up multiple authors.)
Yes, anything that can replicate the name-value possibilities of the meta
element should be fine.
Multiple occurrences make sense for some fields and not for others.
I wonder if we would need to make a defined list of what should go in here
or just define a general mechanism. HTML has a general mechanism (with
meta) while most subtitle formats have a defined set of fileds, e.g.
http://en.wikipedia.org/wiki/LRC_%28file_format%29 (ID3 tags) or
http://www.matroska.org/technical/specs/subtitles/ssa.html (SSA headers).
I'm not sure of the best solution. I'd quite like the ability to use
arbitrary voices, e.g. to use the names/initials of the speaker rather
than
a number, or to use e.g. shouting in combination with CSS :before {
content 'Shouting: ' } or similar to adapt the display for different
audiences (accessibility, basically).
I agree. I think we can go back to usingspan and @class and @id and that
would solve it all.
I guess this is in support of Henri's proposal of parsing the cue using the
HTML fragment parser (same as innerHTML)? That would be easy to implement,
but how do we then mark up speakers? Using span class=narrator/span
around each cue is very verbose. HTML isn't very good for marking up dialog,
which is quite a limitation when dealing with subtitles...
I actually think that the span @class mechanism is much more flexible than
what we have in WebSRT right now. If we want multiple speakers to be able to
speak in the same subtitle, then that's not possible in WebSRT. It's a
little more verbose in HTML, but not massively.
We might be able to add a special markup similar to the [timestamp] markup
that Hixie introduced for Karaoke. This is beyond the innerHTML parser and I
am not sure if it breaks it. But if it doesn't, then maybe we can also
introduce a [voice] marker to be used similarly?
* there is no means to identify which parser is required in the cues (is
it
plain text, minimal markup, or anything?) and therefore it is not
possible for an application to know how it should parse the cues.
All the types that are actually for visual rendering are parsed in the
same
way, aren't they? Of course there's no way for non-browsers to know that
metadata tracks aren't interesting to look at as subtitles, but I think
showing the user the garbage is a quicker to communicate that the file
isn't
for direct viewing than hiding the text or similar.
Re: [whatwg] select element should have a required attribute
On Fri, 18 Jun 2010, Mounir Lamouri wrote:
I'm wondering why select element do not have a required attribute.
It's impossible to submit a select element (without a size= attribute
or multiple= attribute) without it having a value -- essentially,
required= is already implied.
On Thu, 22 Jul 2010, Mounir Lamouri wrote:
1. A typical use case of select is to have option value=''Choose an
option/option as a default value. Having @required would prevent
authors to write any js check when they are using select like that.
That seems like an invalid use of option to me. It would be better as:
label Choose an option: select ... /select /label
2. For select multiple, it is possible to not select any option. The
required attribute can be really helpful here too.
True, required= would be useful in this scenario.
3. Having @required for select will be consistent and semantically
better. As I see it, with HTML5 Forms, I should be able to do
:not(:required) { display: none; } and still be able to submit the form
(I should not hide submit controls actually ;)). So, even for the simple
select's with a non-null default, knowing it is required would be good
for everyone.
This will still work without required=. :-)
The reason select isn't able to use required= currently is still the
same as the reason when this came up in November, as Jon cites here:
On Mon, 9 Aug 2010, Jon Barnett wrote:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-November/017583.html
...namely, we're still waiting for browsers to implement the current crop
of new additions to forms, and adding more will just make them have a more
buggy set of implementations. This feature is in the spec marked as a v2
feature to add at some future point.
I understand the reasoning for not implementing a bunch of new
attributes and functionality, I would still like to see select
required even without the other suggestions as requiring at least one
option element to be successful with a non-empty value.
Currently you can do this just by not providing empty values and not using
multiple= or size=.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Serialization of boolean content attributes
On Fri, 18 Jun 2010, Alexey Proskuryakov wrote: My reading of HTML5 is that boolean content attributes with no value are serialized as e.g. option selected=. That's not what shipping versions of Firefox or IE do, and this markup is invalid per HTML 4, which is a concern for some people. Here are some examples of what Firefox 3.6.3 does, and what would be my preference for WebKit (which currently matches HTML5): option selected - option selected=selected option selected= - option selected=selected option selected=foo - option selected=foo IE is different, and serializes all these examples as option selected. That wouldn't be my preference, since that's invalid XML, but at least it's valid HTML 4. This is tracked as WebKit bug https://bugs.webkit.org/show_bug.cgi?id=22678 On Fri, 18 Jun 2010, Jonas Sicking wrote: Serializing boolean attributes as option selected=selected seems like a very bad idea since that means that you're changing the value as you serialize. I.e. if you roundtrip by for example setting: myDivElement.innerHTML = myDivElement.innerHTML you've change the value of all boolean attribute. Indeed. This leaves us with option selected or option selected= which both parse to the same DOM in HTML. Given that basically everyone uses the first syntax, I would say that that is what we should serialize as. Obviously we don't want to serialize it this way in XHTML documents as this isn't valid XML, so there I say we should serialize as option selected= On Fri, 18 Jun 2010, Darin Adler wrote: This does mean that for HTML the serialization of the attributes depends on the fact that they are boolean attributes. Currently the serialization algorithm in HTML5 doesn't handle attributes differently based on their types. Alexey pointed out to me there no obvious way around this unless we want to end up with things like: option class Instead of: option class= But I agree that serializing as option selected is aesthetically appealing and matches the most popular syntax used in webpages; and the fact that it matches historical IE behavior is a bonus, too. On Fri, 18 Jun 2010, Jonas Sicking wrote: It would be pretty trivial to make the serializer HTML aware and hold a list of which attribute are 'boolean' in which elements, no? It already is HTML aware for a host of other reasons anyway. On Fri, 18 Jun 2010, Darin Adler wrote: One of the things I like about the current serialization rules is that the engine can parse and then serialize something for an element that is not yet known to the engine and it behaves no differently than one that is know. Attributes are simply strings. Having a different rule for boolean attributes would change that. Not a major concern, but something that bothers me slightly. It�s one thing to be HTML-aware and another to be future-of-HTML-aware. On Fri, 18 Jun 2010, Henri Sivonen wrote: Having to have a list of boolean attributes bothers me, too, from a forward compat (and testing) point of view. It's bad enough that the serializer has to have a list of void elements. Since it's possible to make the serializer not require a list of boolean attributes, I think we should choose the path the doesn't require a list. [snip further discussion along these lines] I haven't changed the spec here. I agree with those who say that hard-coding knowledge of boolean attributes is a bad idea since we don't have to. The hard-coded knowledge in the serialiser so far is all knowledge we need to have for compatibility. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=location proposals
On Fri, 18 Jun 2010, Eitan Adler wrote: Two separate use cases 1) For entry of locations into something like Google Maps or MapQuest. In this case the form should look as it does now (a text box) but browsers would be able to assist you in entering locations like it can for for emails. 2) For entry of Lat/Long coordinates which can be entered either manually or with some kind of map like interface. These are two separate proposals and I both could co-exist one as type=location and the other as type=gps Could you give some examples of sites that would use this, and examples of how they're working around the lack of this feature currently? On Sun, 20 Jun 2010, Eitan Adler wrote: For type=gps I was thinking something like the following: 1) type=gps results in a (double?) text box which takes a latitude and a longitude 2a) there is some css option that tells the text box to act like a map instead. 2b) If the css option is on there is also some method of requesting a map source this source could be any existing map provider Then again now that I think about it some more I don't see this working out too well. Does this solve a problem that two type=number controls wouldn't solve? On Fri, 25 Jun 2010, Ashley Sheridan wrote: I think it's quite a fringe case. What about things that are more used: * type=number - a browser could aid input with some sort of spinner * type=price - a browser could use the locale to select a monetary format, or at least display the amount in the locale format specified by the document itself These are just a couple that I think would potentially be more useful than type=location, as I see their use quite a lot. The price one is probably more reserved to CMS's and auction sites, but these are fairly common enough in use I feel. Number could be used for a whole plethora of cases, such as a quantity amount in a shopping cart, an age field in a form, or anything else where you might need a number that wouldn't necessarily be sensible to use a type=range for. Well we have type=number. I don't know that type=price would be _that_ useful; mostly prices are output, not input. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] a element and .text
On Mon, 21 Jun 2010, Olli Pettay wrote: I wonder why a element should have .text which is basically just the same thing as .textContent. I'd prefer removing .text. I'm happy to remove it if we can for compat. On Mon, 21 Jun 2010, Jonas Sicking wrote: I say lets remove it from gecko and see if it breaks any sites. Any news on this? On Mon, 21 Jun 2010, Olli Pettay wrote: I was referring to html5 draft, which specifies that .text should be the same as .textContent. But sure, the reason why gecko has .text is backwards compatibility with Netscape 4. Netscape 4 .text isn't the same as .textContent. Is it different enough that we should change the spec for compat? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Element level XML and XSL attributes
On Mon, 21 Jun 2010, Dr. Clue wrote: Having immensely enjoyed using w3.org standard XML/XSL transforms in my web projects , I would really like the HTML5 spec to consider the addition of two element level attributes (XML and XSL) These two attributes would at a minimum take URLs to the respective .xml and .xsl sources. Use cases include but are not limited to tabular data browsing , charts ,info graphics (SVG etc), news feeds, multi-view data, calenders and miles and miles of common every day activities. If one sees integration of data and presentation in an element of a page, those XML/XSL attributes could handle the vast majority of it. This should not be confused with page wide XSL references like link rel=stylesheet href=mystylesheet.xsl as often these days through various means , elements arrive in a page dynamically. Currently element level XML/XSL transforms require vendor specific object sniffing hacks to achieve those transforms, and having XML and XSL attributes while having a main merit all their own has the added benefit of eliminating the need for those hacks. These attributes also decrease the complexity of having multiple contributors collaborating on a page by allowing individual elements of presentation involving data and structure to be built standalone , and then integrated into any page presentation. As an additional option it might be nice if the attributing setting would allow the values to be either the typical URLs or the native Javascript objects created through the browser's Javascript API, although this latter aspect would simply be gravy. Making the w3.org XML/XSL standards more accessible from HTML has an amazing bounty of benefits and would be trivial for vendors to implement, since the internal code is in browsers (include gasp IE) going back a long long ways. I've been wishing for these attributes to appear for years, and the thought occurred to me yet again today as I embark on yet another project where XML/XSL will take a primary role in keeping my data separate from my presentation. I encourage you to follow the process described in the FAQ for adding new features: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] select element should have a required attribute
On Mon, Aug 9, 2010 at 4:35 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 18 Jun 2010, Mounir Lamouri wrote: I'm wondering why select element do not have a required attribute. It's impossible to submit a select element (without a size= attribute or multiple= attribute) without it having a value -- essentially, required= is already implied. On Thu, 22 Jul 2010, Mounir Lamouri wrote: 1. A typical use case of select is to have option value=''Choose an option/option as a default value. Having @required would prevent authors to write any js check when they are using select like that. That seems like an invalid use of option to me. It would be better as: label Choose an option: select ... /select /label Many times you want the user to make an explicit choice, rather than just leaving whatever was already selected. What many websites do is: labelChoose an option: select option/option optionvalue 1/option optionvalue 2/option optionvalue 3/option /select /label Or select option value=Choose an option:/option optionvalue 1/option optionvalue 2/option optionvalue 3/option /select It would be good if it was possible to use @required together with these usage patterns. I don't believe that any other feature of HTML supplies the same, or similar, functionality? While authors could do labelChoose an option: select optionvalue 1/option optionvalue 2/option optionvalue 3/option /select /label I think there is a reason they haven't done so so far, and I don't see that HTML5 changes any of those reasons. While I guess we could wait for v2 for this feature, it seems like a glaring omission and inconsistency in the way that @required works. / Jonas
Re: [whatwg] Navigation maturation and event loops
On Wed, 23 Jun 2010, Ben Lerner wrote: I'm trying to figure out the control flow when documents are loaded and navigated, and I think there's a deadlock situation (at least as I'm currently reading the spec). http://www.whatwg.org/specs/web-apps/current-work/#read-html: After creating the Document object, but before any script execution, certainly before the parser stops, the user agent must update the session history with the new page. http://www.whatwg.org/specs/web-apps/current-work/#update-the-session-history-with-the-new-page: ...The user agent must queue a task to ... #3: The navigation algorithm has now matured. http://www.whatwg.org/specs/web-apps/current-work/#queue-a-task: When a user agent is to queue a task, it must add the given task to one of the task queues of the relevant event loop. http://www.whatwg.org/specs/web-apps/current-work/#processing-model-2: An event loop must continually run through the following steps for as long as it exists: 1. Run the oldest task on one of the event loop's task queues, ignoring tasks whose associated Documents are not fully active. http://www.whatwg.org/specs/web-apps/current-work/#fully-active: A Document is said to be fully active when it is the active document of its browsing context, and ... So if I'm reading that chain right: I need to queue a task that will mature the navigation algorithm, which will make the document the active document, except that the task will not run because the document is not yet the active document and hence not fully active. The loophole here is the phrase relevant event loop. Is there an event loop that is relevant and that is also associated with a fully-active document? The associated document in the case of the task that updates the session history with the new page is the previous document, not the new one. I'll make that clearer. Does that leave anything unclear for you? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML5 video source dimensions and bitrate
Have you looked at the @media attribute? I would suggest to put them there. As that's not currently specified in media queries, you might want to demonstrate how it could work and make a proposal to extend the media queries. Cheers, Silvia. On Tue, Aug 10, 2010 at 9:00 AM, Zachary Ozer z...@longtailvideo.comwrote: Hello! I'm working on some bandwidth switching logic for the JW Player for HTML5. The way that we've implemented our bandwidth switching logic relies on knowing both the dimensions of the video as well as it's bitrate (for more info on the logic, see our dynamic streaming documentation [1]). MRSS supports this quite nicely, as their media content elements allow for width, height, and bitrate, per our example [2]. As a result, I was wondering if there's some way to attach metadata like the dimensions and bitrate to source elements of HTMLMediaElements in the DOM. I realize that we could wait for metadata to arrive for each source, but it would be nice if it was possible to make an intelligent choice before attempting to play all of them. Best, Zach [1] : http://www.longtailvideo.com/support/jw-player/jw-player-for-flash-v4/12208/video-delivery-rtmp-streaming#dynamicstreaming [2] : http://developer.longtailvideo.com/player/testing/files/bitrates.xml -- Zachary Ozer Developer, LongTail Video w: longtailvideo.com • e: z...@longtailvideo.com • p: 212.244.0140 • f: 212.656.1335 JW Player | Bits on the Run | AdSolution
Re: [whatwg] select element should have a required attribute
On 08/10/2010 01:35 AM, Ian Hickson wrote:
On Fri, 18 Jun 2010, Mounir Lamouri wrote:
I'm wondering why select element do not have a required attribute.
It's impossible to submit a select element (without a size= attribute
or multiple= attribute) without it having a value -- essentially,
required= is already implied.
If you ignore that a lot of select (with no size and no multiple) have
their first option with only a label and no value to force the user to
intentionally choose an option.
3. Having @required for select will be consistent and semantically
better. As I see it, with HTML5 Forms, I should be able to do
:not(:required) { display: none; } and still be able to submit the form
(I should not hide submit controls actually ;)). So, even for the simple
select's with a non-null default, knowing it is required would be good
for everyone.
This will still work without required=. :-)
Indeed, HTMl5 Forms form validation system will not block the form
submission but a lot of select in forms are actually required and, in
that case js checks will very likely block the form submission. That may
be a bad experience for the user (UA validation system and website
validation system may be inconsistent) and that is definitely a bad
experience for the authors who can't fully use the required attribute
and will have to keep their js checks only for required select's (see
Jon Barnett's email).
--
Mounir
Re: [whatwg] When are sandboxing flags set?
On Thu, 24 Jun 2010, Ben Lerner wrote: The 22 June 2010 spec says in section 6.5.1 Navigating across documents: If the source browsing context is not the same as the browsing context being navigated, ..., and the source browsing context had its sandboxed navigation browsing context flag set when its active document was created, then abort these steps. When exactly is its active document created? For HTML documents, it happens as part of the navigation algorithm, when it parses the HTML file (first sentence): http://www.whatwg.org/specs/web-apps/current-work/complete.html#read-html I can read this clause in several ways: * When documents are created they must set the sandboxed navigation browsing context flag on their browsing context. But documents are created before they are active in some browsing context, so that seems wrong. * When documents are set as active within a browsing context. But that doesn't sound like creation time, so that seems wrong too. * At the instant the document was allocated, the browsing context happened to record its current context flags despite the document not being active in the browsing context yet. But that seems implausible at best. It's the latter, at least as specced. Why is it implausible? Additionally, the sandboxing flags seem to be more a feature of the iframe element than of the browsing context, because they depend on the value of the iframe's sandbox attribute. Can these flags ever be set on a top-level browsing context? No, correct? Currently, yes, but there's no reason for that to remain the case. The spec then talks about the seamless browsing context flag. Is this flag distinct from the sandbox-seamless-iframes flag? And when is this flag set? Yes, the two are distinct. It is set automatically when the iframe has the seamless attribute set, as per the iframe section. It seems different from the others, because it can be set by manipulating content attributes: Specifically, when the attribute is set on an iframe element whose owner Document's browsing context did not have the sandboxed seamless iframes flag set when that Document was created, and while either the browsing context's active document has the same origin as the iframe element's document, or the browsing context's active document's address has the same origin as the iframe element's document, the following requirements apply: The user agent must set the seamless browsing context flag to true for that browsing context. This will cause links to open in the parent browsing context. WARNING! It is important that user agents recheck the above conditions whenever the active document of the nested browsing context of the iframe changes, such that the seamless browsing context flag gets unset if the nested browsing context is navigated to another origin. Again the question of when the document was created. Additionally, the seamless flag refers to the iframe, the iframe's owner document, the iframe's owner document's browsing context, and the iframe's browsing context itself. These don't seem intrinsically like flags on the browsing context... Well they're only set on browsing contexts that are inside iframes, and there's a 1:1 mapping of iframe to browsing context, so you could look at it either way. I just did it in terms of the browsing context since that's more flexible and doesn't require us to keep checking for an iframe. Are there any other flags that might apply to browsing contexts that might equally well apply to iframes instead? I can't think of any off-hand. On Wed, 23 Jun 2010, Adam Barth wrote: [...] how we interpreted this on WebKit: 1) When a Document object is allocated, it is either associated with a browsing context (which we call a Frame) or it isn't. It's an invariant that a Document object can never become an active document of a Frame unless the Document was associated with that Frame when it was allocated. This is the case in the spec also. 2) If the Document object is associated with a Frame, then we check whether that Frame is an iframe element in another document. 3) If so, we copy the sandbox bits from the iframe element into the document, freezing them. This seems conformant. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] select element should have a required attribute
On Mon, Aug 9, 2010 at 4:54 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Aug 9, 2010 at 4:35 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 18 Jun 2010, Mounir Lamouri wrote: I'm wondering why select element do not have a required attribute. It's impossible to submit a select element (without a size= attribute or multiple= attribute) without it having a value -- essentially, required= is already implied. On Thu, 22 Jul 2010, Mounir Lamouri wrote: 1. A typical use case of select is to have option value=''Choose an option/option as a default value. Having @required would prevent authors to write any js check when they are using select like that. That seems like an invalid use of option to me. It would be better as: label Choose an option: select ... /select /label Many times you want the user to make an explicit choice, rather than just leaving whatever was already selected. What many websites do is: labelChoose an option: select option/option optionvalue 1/option optionvalue 2/option optionvalue 3/option /select /label Or select option value=Choose an option:/option optionvalue 1/option optionvalue 2/option optionvalue 3/option /select It would be good if it was possible to use @required together with these usage patterns. I don't believe that any other feature of HTML supplies the same, or similar, functionality? While authors could do labelChoose an option: select optionvalue 1/option optionvalue 2/option optionvalue 3/option /select /label I think there is a reason they haven't done so so far, and I don't see that HTML5 changes any of those reasons. While I guess we could wait for v2 for this feature, it seems like a glaring omission and inconsistency in the way that @required works. There is another reason to introduce @required on select now, rather than in v2. We're already seeing a small amount of complexity in introducing @required because it's preventing existing sites from working due to sites already having elements with a 'required' attribute. And this is in a situation where @required has never been part of any specificiation. It is likely that if @required gains traction, which I think we're all hoping for, that sites will use 'required' attributes on select elements. This might work just fine as long as browsers ignore this attribute. However once browsers attempt to deploy v2, there is a big risk that many of these sites will stop working. We could specify in v1 that @required on select always prevents the form from submitting, that would make it easier for browsers to implement v2. However that would make it harder for sites to deploy v2 since it would prevent the site from working in any old browsers that only support v1. Thus I recommend that we add @required now. / Jonas
Re: [whatwg] HTML5 video source dimensions and bitrate
On Tue, Aug 10, 2010 at 11:00 AM, Zachary Ozer z...@longtailvideo.com wrote: As a result, I was wondering if there's some way to attach metadata like the dimensions and bitrate to source elements of HTMLMediaElements in the DOM. I realize that we could wait for metadata to arrive for each source, but it would be nice if it was possible to make an intelligent choice before attempting to play all of them. You don't get metadata for each source, you only get the metadata for the source that is actually selected to play. I don't think listing video's which are only different due to bitrate in the source as being a good approach since most players will iterate through all sources trying to play them. So if you have 5 '.ogg' videos first in the source list, different only by bitrate, a non-ogg player is going to check each of those, possibly sniffing them and causing network traffic. Since your player is already JavaScript is having a JS object holding the URL, dimensions and bitrate not an option? Or you could have a seperate file that is retrieved via XMLHttpRequest that is parsed to extract these details and dynamically adjust 'source' elements after that? How are you working out the current playback rate to decide when to switch to a different bitrate version? Is having an attribute of the media element that contains this information useful? Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] select element should have a required attribute
On Mon, 2010-08-09 at 16:54 -0700, Jonas Sicking wrote: On Mon, Aug 9, 2010 at 4:35 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 18 Jun 2010, Mounir Lamouri wrote: I'm wondering why select element do not have a required attribute. It's impossible to submit a select element (without a size= attribute or multiple= attribute) without it having a value -- essentially, required= is already implied. On Thu, 22 Jul 2010, Mounir Lamouri wrote: 1. A typical use case of select is to have option value=''Choose an option/option as a default value. Having @required would prevent authors to write any js check when they are using select like that. That seems like an invalid use of option to me. It would be better as: label Choose an option: select ... /select /label Many times you want the user to make an explicit choice, rather than just leaving whatever was already selected. What many websites do is: labelChoose an option: select option/option optionvalue 1/option optionvalue 2/option optionvalue 3/option /select /label Or select option value=Choose an option:/option optionvalue 1/option optionvalue 2/option optionvalue 3/option /select It would be good if it was possible to use @required together with these usage patterns. I don't believe that any other feature of HTML supplies the same, or similar, functionality? While authors could do labelChoose an option: select optionvalue 1/option optionvalue 2/option optionvalue 3/option /select /label I think there is a reason they haven't done so so far, and I don't see that HTML5 changes any of those reasons. While I guess we could wait for v2 for this feature, it seems like a glaring omission and inconsistency in the way that @required works. / Jonas This is wrong in my opinion, it just doesn't make sense to have loads of empty elements. Select lists get used for a lot of wrong things sometimes, such as a year picker (of which there are many tales on the daily wtf where the data range just isn't well thought out) Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
I'd just say that there might be a demand for this feature in Japan (if localized properly) because all official government document needs to dated with era name (http://en.wikipedia.org/wiki/Japanese_era_name). Some banks even implement their internal database systems using era system, and it's always cumbersome for humans to convert between era and Gregorian year. Best, Ryosuke Niwa On Sun, Aug 8, 2010 at 6:11 PM, Kit Grose k...@iqmultimedia.com.au wrote: The field being four digits long doesn't restrict its contents to four digits only. I suppose you do raise an interesting concern; should the year field also permit the entry of BC/AD? If so, that might invalidate the ability to use a number field; you'd need to use a validation pattern on a standard text field. —Kit On 09/08/2010, at 10:46 AM, Andy Mabbett wrote: On Mon, August 9, 2010 00:44, Kit Grose wrote: How is a year input any different from a four-digit input type=number field? Years can be more of fewer than four digits. Julius Caesar was born in 100 BC, for instance, while Manius Acilius Glabrio was consul in 91 AD. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] Allowing in attribute values
On Wed, 23 Jun 2010, Benjamin M. Schwartz wrote: The HTML5 spec appears to allow inside an attribute value. For example, the following page (note the body tag) passes the experimental HTML5 validator at w3c.org: !DOCTYPE HTMLhtmlheadtitle/title/head body class=32 /body/html I think should be disallowed inside attribute values. What problem would this solve? It is disallowed in XHTML (I assume you mean is disallowed in XHTML.) Convergence with XML syntax rules is not a goal. Being a superset of those rules where possible is a minor secondary goal, but that is achieved either way in this case. It is disallowed in HTML 4.01 Convergence with HTML4 is not a goal. Disallowing it in HTML5 would avoid unnecessary divergence, and also sometimes simplify parsing. It wouldn't affect parsing. A goal of HTML5 is to make the language have no useless restrictions. This argues for enabling people to put characters like in attributes. On Thu, 24 Jun 2010, Kornel Lesinski wrote: I see other argument against allowing in attributes: it helps to catch unclosed attributes early: a href=foo This kind of error in practice gets caught soon enough anyway. On Thu, 24 Jun 2010, Benjamin M. Schwartz wrote: Worldwide, regarding HTML, I'm sure there is 100 times more regular expression processing code than full-on lexing code. Most code that processes HTML is embedded in scripts, doing some small special-purpose operation. Those regular expressions aren't going away. Helping them break less is a noble cause. On the contrary, the more they break the less likely it is they will continue to be used. In practice, there is no way to use regular expressions reliably with HTML. We shouldn't encourage it. On Fri, 25 Jun 2010, Lachln Hunt wrote: You seem to be conflating document conformance requirements with parsing requirements. Even if '' was disallowed in attribute values for document conformance, parsers would still be required to handle it if it were present. If your parser doesn't handle it because it just assumes that '' is the end of the tag name, then your paser is broken. Changing the parsing requirements such that '' is treated as the end of a tag, in places where it's currently treated as part of an attribute value, would break backwards compatibility. Indeed. On Fri, 25 Jun 2010, Benjamin M. Schwartz wrote: That's more or less how I feel. The spec places requirements on how user agents, data mining tools, and conformance checkers must handle non-conforming input, but there are many other things in the world that process HTML. In other applications, it may be acceptable to have undefined behavior on non-conforming input, like in ISO C. I don't think it's every acceptable to have undefined behaviour on issues as critical as how to parse a document, valid or not. HTML5 has a very clear specification of conformance, and a validator is widely available. If I build a tool that guarantees correct behavior only on conforming inputs, then users can easily check their documents for conformance before using my tool. If my tool has additional restrictions, then I need to write my own validator, and answer a lot of questions. I recommend just using a conforming HTML parser. I was inspired to suggest this restriction after using mod_layout for Apache, which inserts a banner at the top of a page. It works by doing a wildcard search for body*. There are a number of obvious ways to break this [1]; one of them is by having in an attribute value. I'm sure there are many thousands of such programs around the world. They should be fixed. :-) It sounds like most experts here would prefer to allow in attribute values in conforming documents, and that's fine. I don't fully understand the advantage, but I won't argue against consensus. Expert opinions and consensus aren't the law of the land here, it's use cases, arguments, and most importantly data that count. See Philip`'s comment at the very bottom of this e-mail. [1] A javascript line like widthbodywidth heightbodyheight would also break it, as would an appropriately constructed comment. It might be possible to construct a regexp for this that functions correctly on all conformant HTML5 documents. Such a regexp would be considerably simpler if were disallowed in attribute values. Regular expressions are the wrong tool for parsing HTML. HTML isn't regular. On Tue, 29 Jun 2010, Skrol29 wrote: Replacing with gt; is already a good practice in XML and HTML. Why? doesn't mean anything special where it could be confused for text except in unquoted attribute values, and good practice there is to quote attribute values whose values are free-form text. Some HTML attributes already forbid it (it is allowed in CDATA attributes, forbidden in %Text attributes). This doesn't apply anymore. Since XML 2 has been stopped, I think
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
On Mon, Aug 9, 2010 at 8:36 AM, Andy Mabbett a...@pigsonthewing.org.ukwrote: On Mon, August 9, 2010 15:10, Daniel Glazman wrote: Le 09/08/10 03:11, Kit Grose a écrit : should the year field also permit the entry of BC/AD? Or a jewish year? Or a muslim year? Or counting since the first tooth of Carolus Magnus or the last onomatopoeia pronounced by Hannibal during his crossing of the Alps? All popular calendar systems should be supported. What is the reason we restrict ourselves to Gregorian calendar? Best, Ryosuke
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
On Mon, Aug 9, 2010 at 5:41 PM, Ryosuke Niwa ryosuke.n...@gmail.com wrote: On Mon, Aug 9, 2010 at 8:36 AM, Andy Mabbett a...@pigsonthewing.org.uk wrote: On Mon, August 9, 2010 15:10, Daniel Glazman wrote: Le 09/08/10 03:11, Kit Grose a écrit : should the year field also permit the entry of BC/AD? Or a jewish year? Or a muslim year? Or counting since the first tooth of Carolus Magnus or the last onomatopoeia pronounced by Hannibal during his crossing of the Alps? All popular calendar systems should be supported. What is the reason we restrict ourselves to Gregorian calendar? The Gregorian calendar is the de facto official calendar of the world. Mixing in other calendars is a horrendous nightmare with nearly zero benefit. ~TJ
Re: [whatwg] select element should have a required attribute
On Mon, Aug 9, 2010 at 5:26 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: On Mon, 2010-08-09 at 16:54 -0700, Jonas Sicking wrote: On Mon, Aug 9, 2010 at 4:35 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 18 Jun 2010, Mounir Lamouri wrote: I'm wondering why select element do not have a required attribute. It's impossible to submit a select element (without a size= attribute or multiple= attribute) without it having a value -- essentially, required= is already implied. On Thu, 22 Jul 2010, Mounir Lamouri wrote: 1. A typical use case of select is to have option value=''Choose an option/option as a default value. Having @required would prevent authors to write any js check when they are using select like that. That seems like an invalid use of option to me. It would be better as: label Choose an option: select ... /select /label Many times you want the user to make an explicit choice, rather than just leaving whatever was already selected. What many websites do is: labelChoose an option: select option/option optionvalue 1/option optionvalue 2/option optionvalue 3/option /select /label Or select option value=Choose an option:/option optionvalue 1/option optionvalue 2/option optionvalue 3/option /select It would be good if it was possible to use @required together with these usage patterns. I don't believe that any other feature of HTML supplies the same, or similar, functionality? While authors could do labelChoose an option: select optionvalue 1/option optionvalue 2/option optionvalue 3/option /select /label I think there is a reason they haven't done so so far, and I don't see that HTML5 changes any of those reasons. While I guess we could wait for v2 for this feature, it seems like a glaring omission and inconsistency in the way that @required works. / Jonas This is wrong in my opinion, it just doesn't make sense to have loads of empty elements. Select lists get used for a lot of wrong things sometimes, such as a year picker (of which there are many tales on the daily wtf where the data range just isn't well thought out) I don't really understand what you are proposing. Many sites seem to want to have users make an explicit choice. What do you propose that they do? / Jonas
[whatwg] Question on iframe.srcdoc address (about:srcdoc)
I'm working on implementing iframe.srcdoc in WebKit, and section 2.5.1 states: This specification defines the URL about:srcdoc as a reserved, though unresolvable, about: URI, that is used as the document's address of iframe srcdoc documents. It seems like it would make more sense for the address to be the data URL of the frame's document. This would be easier to implement in WebKit, and I expect other data URL supporting browsers as well. Is there some reasoning I'm missing for the decision to use about:srcdoc? Thanks, Justin
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
On 10/08/2010, at 10:44 AM, Tab Atkins Jr. wrote: On Mon, Aug 9, 2010 at 5:41 PM, Ryosuke Niwa ryosuke.n...@gmail.com wrote: On Mon, Aug 9, 2010 at 8:36 AM, Andy Mabbett a...@pigsonthewing.org.uk wrote: On Mon, August 9, 2010 15:10, Daniel Glazman wrote: Le 09/08/10 03:11, Kit Grose a écrit : should the year field also permit the entry of BC/AD? Or a jewish year? Or a muslim year? Or counting since the first tooth of Carolus Magnus or the last onomatopoeia pronounced by Hannibal during his crossing of the Alps? All popular calendar systems should be supported. What is the reason we restrict ourselves to Gregorian calendar? The Gregorian calendar is the de facto official calendar of the world. Mixing in other calendars is a horrendous nightmare with nearly zero benefit. ~TJ All the more reason for simply letting page authors define any fields they need using the existing input primitives like number. I think putting the onus for this sort of investigation on the UA will simply mean this won't get implemented. Is any of this discussion being had for the existing date type? The existing spec simply says a year must be Four or more digits, representing year, where year 0. I think all of this is important discussion not explicitly related to the need for a new input of type year. The question we need to identify is whether there's additional value (semantic or otherwise) in defining input type=year distinctly from a textual/numeric input with name=year. The precise behaviour of any such field is surely dependent on an agreement that its existence is valuable. —Kit
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
I don't understand why I would need an input type=year to get this right though. If the bank wants something in 年号 it can just let the user type in 1985 and convert that via JS to 昭和60年, no? If anything, having some sort of picker seems like it would be more complicated. Frankly, this seems a bit over-complicated. The number of times a user will be entering a year other than 1900-present has got to be infinitesimally small. In reflecting upon the years I've entered, it'a almost always been a living person's date of birth, some event I was scheduling, a date for something I was purchasing (e.g. airline ticket), or the present date. I really don't know if it's worth spending time on something that is such a minor use case, and can frankly be handled fine without a dedicated input type. And niwa-san, on every document I've ever filled out for the Japanese government, I've always written 1985年 instead of 昭和60年 and it's yet to cause me any problems ;-) I do understand that there are some sites that want it written in the traditional form, but these seem to be precious few and far between, and frankly are not the sites I would expect to find HTML5 form input elements on anyways if the US government is any indication of moving to new standards... On Mon, Aug 9, 2010 at 5:33 PM, Ryosuke Niwa ryosuke.n...@gmail.com wrote: I'd just say that there might be a demand for this feature in Japan (if localized properly) because all official government document needs to dated with era name (http://en.wikipedia.org/wiki/Japanese_era_name). Some banks even implement their internal database systems using era system, and it's always cumbersome for humans to convert between era and Gregorian year. Best, Ryosuke Niwa On Sun, Aug 8, 2010 at 6:11 PM, Kit Grose k...@iqmultimedia.com.au wrote: The field being four digits long doesn't restrict its contents to four digits only. I suppose you do raise an interesting concern; should the year field also permit the entry of BC/AD? If so, that might invalidate the ability to use a number field; you'd need to use a validation pattern on a standard text field. —Kit On 09/08/2010, at 10:46 AM, Andy Mabbett wrote: On Mon, August 9, 2010 00:44, Kit Grose wrote: How is a year input any different from a four-digit input type=number field? Years can be more of fewer than four digits. Julius Caesar was born in 100 BC, for instance, while Manius Acilius Glabrio was consul in 91 AD. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] select element should have a required attribute
On 8/9/10, Jonas Sicking jo...@sicking.cc wrote: On Mon, Aug 9, 2010 at 4:35 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 18 Jun 2010, Mounir Lamouri wrote: I'm wondering why select element do not have a required attribute. It's impossible to submit a select element (without a size= attribute or multiple= attribute) without it having a value -- essentially, required= is already implied. select id=p option selected disabled /select Is not interoperable. In some browsers (IE7 an below, Webkit) submitting the form results in the SELECT being submitted with disabled option having the value, while in other browsers (Gecko), SELECT is not successful. This was discussed here before. On Thu, 22 Jul 2010, Mounir Lamouri wrote: 1. A typical use case of select is to have option value=''Choose an option/option as a default value. Having @required would prevent authors to write any js check when they are using select like that. That seems like an invalid use of option to me. It would be better as: label Choose an option: select ... /select /label Many times you want the user to make an explicit choice, rather than just leaving whatever was already selected. What many websites do is: labelChoose an option: select option/option optionvalue 1/option optionvalue 2/option optionvalue 3/option /select /label The first option should be selected, resulting in the select having value=. If `required` is specified, and the user selects an empty option (the first option in the list) and submits the form, what do you think should happen? Or select option value=Choose an option:/option optionvalue 1/option optionvalue 2/option optionvalue 3/option /select What should happen if the SELECT has `required`? It would be good if it was possible to use @required together with these usage patterns. I don't believe that any other feature of HTML supplies the same, or similar, functionality? While authors could do [...] While I guess we could wait for v2 for this feature, it seems like a glaring omission and inconsistency in the way that @required works. I've seen sites that require the user to pick a SELECT value, sure. I was just using Bing.com search feedback which requires that. Bing.com search feedback form is not the best example of the need for this feature, though because it throws multiple javascript errors and fails to submit in Firefox 3.6. I know I've seen other sites using this before but can't think of them right now. Garrett
Re: [whatwg] HTML resource packages
The files I used for the rough benchmarks are available in a tarball at [1]. Live pages are at [2] and [3]. [1] http://people.mozilla.org/~jlebar/respkg/test/benchmark_files.tgz [2] http://people.mozilla.org/~jlebar/respkg/test/test-pkg.html [3] http://people.mozilla.org/~jlebar/respkg/test/test-nopkg.html -Justin On Mon, Aug 9, 2010 at 1:40 PM, Justin Lebar justin.le...@gmail.com wrote: Can you provide the content of the page which you used in your whitepaper? (https://bug529208.bugzilla.mozilla.org/attachment.cgi?id=455820) I'll post this to the bug when I get home tonight. But your comments are astute -- the page I used is a pretty bad benchmark for a variety of reasons. It sounds like you probably could hack up a much better one. a) Looks like pages were loaded exactly once, as per your notes? How hard is it to run the tests long enough to get to a 95% confidence interval? Since I was running on a simulated network with no random parameters (e.g. no packet loss), there was very little variance in load time across runs. d) What did you do about subdomains in the test? I assume your test loaded from one subdomain? That's correct. I'm betting time-to-paint goes through the roof with resource bundles:-) It does right now because we don't support incremental extraction, which is why I didn't bother measuring time-to-paint. The hope is that with incremental extraction, we won't take too much of a hit. -Justin On Mon, Aug 9, 2010 at 1:30 PM, Mike Belshe m...@belshe.com wrote: Justin - Can you provide the content of the page which you used in your whitepaper? (https://bug529208.bugzilla.mozilla.org/attachment.cgi?id=455820) I have a few concerns about the benchmark: a) Looks like pages were loaded exactly once, as per your notes? How hard is it to run the tests long enough to get to a 95% confidence interval? b) As you note in the report, slow start will kill you. I've verified this so many times it makes me sick. If you try more combinations, I believe you'll see this. c) The 1.3MB of subresources in a single bundle seems unrealistic to me. On one hand you say that its similar to CNN, but note that CNN has JS/CSS/images, not just thumbnails like your test. Further, note that CNN pulls these resources from multiple domains; combining them into one domain may work, but certainly makes the test content very different from CNN. So the claim that it is somehow representative seems incorrect. For more accurate data on what websites look like, see http://code.google.com/speed/articles/web-metrics.html d) What did you do about subdomains in the test? I assume your test loaded from one subdomain? e) There is more to a browser than page-load-time. Time-to-first-paint is critical as well. For instance, in WebKit and Chrome, we have specific heuristics which optimize for time-to-render instead of total page load. CNN is always cited as a bad page, but it's really not - it just has a lot of content, both below and above the fold. When the user can interact with the page successfully, the user is happy. In other words, I know I can make webkit's PLT much faster by removing a couple of throttles. But I also know that doing so worsens the user experience by delaying the time to first paint. So - is it possible to measure both times? I'm betting time-to-paint goes through the roof with resource bundles:-) If you provide the content, I'll try to run some tests. It will take a few days. Mike On Mon, Aug 9, 2010 at 9:52 AM, Justin Lebar justin.le...@gmail.com wrote: On Mon, Aug 9, 2010 at 9:47 AM, Aryeh Gregor simetrical+...@gmail.com wrote: If UAs can assume that files with the same path are the same regardless of whether they came from a resource package or which, and they have all but a couple of the files cached, they could request those directly instead of from the resource package, even if a resource package is specified. These kinds of heuristics are far beyond the scope of resource packages as we're planning to implement them. Again, I think this type of behavior is the domain of a large change to the networking stack, such as SPDY, not a small hack like resource packages. -Justin On Mon, Aug 9, 2010 at 9:47 AM, Aryeh Gregor simetrical+...@gmail.com wrote: On Fri, Aug 6, 2010 at 7:40 PM, Justin Lebar justin.le...@gmail.com wrote: I think this is a fair point. But I'd suggest we consider the following: * It might be confusing for resources from a resource package to show up on a page which doesn't opt-in to resource packages in general or to that specific resource package. Only if the resource package contains a different file from the real one. I suggest we treat this as a pathological case and accept that it will be broken and confusing -- or at least we consider how many extra optimizations we could make if we did accept that, before deciding whether the
