A. In such case, make input.validity.typeMismatch true, or
B. Introduce new IDL attribute to ValidityState.
input.validity.invalidUserInput?
C. Just validity.valid becomes false.
An implementation would have an internal flag like invalidUserInput, but
it won't be exposed via IDL.
C would hav
On Fri, Oct 26, 2012 at 3:09 AM, Anne van Kesteren wrote:
> On Fri, Oct 26, 2012 at 10:01 AM, Adam Barth wrote:
> > When should the UA offer to fill in the form (e.g., to select which
> > address they would like to use for shipping this particular order)?
>
> Presumably on page load.
>
>
It was
Hi Whatwg!
I'm continuing to work on , an API in WebKit,
implemented by Chrome, which allows applications to request pages be loaded
early for faster navigation. This is a leading cause of 0ms navigations on
the web!
As we've explored this feature, we've continued to add to the API to allow
more
On Thu, 8 Nov 2012, Ben Schwarz wrote:
>
> What does concern me, as a web builder, *every day*, is how I markup the
> content in-between a and a .
If you just want it for styling purposes, is perfect.
>
> h1, h2, p
>
> time, a.permalink
>
Exactly like that (or even without the class, if y
In response to Silvia's comments—
I think relying on is a pretty good result, I think we need to
stretch further.
An is a piece of content that isn't semantically defined on its
parents. (right?)
Shouldn't we have a way to define this without confusing the "main" content of
the 'page'?
"Skip to main" isn't the only use case :-)
FYI, as a web designer, (slap me here) I've almost never designed in a "skip to
main" link.
Call me ignorant (probably fitting), but in the "real world" a new way to
markup 'skip to main' isn't on my mind.
What does concern me, as a web builder, *eve
On Thu, Nov 8, 2012 at 3:00 AM, Markus Ernst wrote:
> Am 07.11.2012 15:48 schrieb Jukka K. Korpela:
>
> I suppose that the heuristics would include recognizing a element
>> to which class "main" has been assigned. Then one could argue that
>> is not needed, as authors can keep using , as
>> mi
On Wed, 7 Nov 2012, Simon Pieters wrote:
>
> My impression from TPAC is that implementors are on board with the idea
> of adding to HTML, and we're left with Hixie objecting to it.
If implementors wish to implement something, my objecting is irrelevant. :-)
Just implement it.
> Hixie's argum
As a developer I'm in favor of this. Just take a look at the how
popular the question of "How do I enable Reader mode" is on SO[1], and
how complex and mysterious the actual algorithm appears to be[2], and
it's evident how authors and implementors alike could benefit from a
dedicated element.
Alth
(12/11/08 1:48), James Graham wrote:
> I think that finding the main content of a page has clear use cases. We
> can see examples of authors working around the lack of this feature in
> the platform every time they use a "skip to main" link, or (less
> commonly) aria role=main. I believe we also se
On 11/07/2012 05:52 PM, Ojan Vafai wrote:
On Wed, Nov 7, 2012 at 6:23 AM, Simon Pieters wrote:
My impression from TPAC is that implementors are on board with the idea of
adding to HTML, and we're left with Hixie objecting to it.
For those of use who couldn't make it, which browser vendors
On Wed, Nov 7, 2012 at 6:23 AM, Simon Pieters wrote:
> My impression from TPAC is that implementors are on board with the idea of
> adding to HTML, and we're left with Hixie objecting to it.
>
For those of use who couldn't make it, which browser vendors voiced
support? I assume Opera since you'
Am 07.11.2012 15:48 schrieb Jukka K. Korpela:
I suppose that the heuristics would include recognizing a element
to which class "main" has been assigned. Then one could argue that
is not needed, as authors can keep using , as
millions of pages use.
I doubt that this is useable for that kind of
2012-11-07 16:53, Steve Faulkner wrote:
ARIA roles are used because the semantics are not fully implemented in
browsers yet.
It's a bit more complicated than that, isn't it? ARIA roles are also,
and originally, meant for describing the meaning of elements that are
used in "rich Internet appl
On Wed, 07 Nov 2012 15:35:31 +0100, Ben Schwarz
wrote:
I generally markup pages using ARIA roles:
There is an implicit mapping already.
and variations thereafter—
If there were to be a attribute (with an implicit ARIA role to
match), where would it end?
It ends at since that's
Steve, you never fail to amaze me. (Thank you!)
So, with it laid out as clearly as that, the glaringly obvious missing element
is . (Thank you Simon)
Over to you, @Hixie.
On 08/11/2012, at 1:53 AM, Steve Faulkner wrote:
> Hi Ben,
>
> I generally markup pages using ARIA roles:
>
>
>
>
Hi Ben,
> I generally markup pages using ARIA roles:
>
>
>
>
>
> and variations thereafter—
>
> If there were to be a attribute (with an implicit ARIA role to
> match), where would it end? ?
> What is to be gained by adding an element, rather than using ARIA roles?
> Isn't that what ARIA is
2012-11-07 16:23, Simon Pieters wrote:
Hixie's argument is, I think, that the use case that is intended
to address is already possible by applying the Scooby-Doo algorithm, as
James put it -- remove all elements that are not main content, ,
, etc., and you're left with the main content.
Hixie
I generally markup pages using ARIA roles:
and variations thereafter—
If there were to be a attribute (with an implicit ARIA role to match),
where would it end? ?
What is to be gained by adding an element, rather than using ARIA roles? Isn't
that what ARIA is designed for?
On 08/11/
Hi,
My impression from TPAC is that implementors are on board with the idea of
adding to HTML, and we're left with Hixie objecting to it.
Hixie's argument is, I think, that the use case that is intended to
address is already possible by applying the Scooby-Doo algorithm, as James
put it
Hi
https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html
says
[[
The User Agent style sheet should include the following style rule for the
main element:
main {
display:block;
}
]]
I think this is a bit inconsistent with the HTML spec.
First, it should be cle
On Wed, 07 Nov 2012 13:47:53 +0100, Henri Sivonen wrote:
On Wed, Nov 7, 2012 at 2:42 PM, Simon Pieters wrote:
I think we shouldn't put the parsing algorithm on a pedestal while not
giving the same treatment to the default UA style sheet or other
requirements related to an element that have to
On 7.11.2012 13:42, Simon Pieters wrote:
>> Look for example at . It's supported by parsing algorithm as
>> implemented in browsers, so it will remain in spec forever even when
>> it's not actually implemented. With such approach parsing algorithm will
>> became boneyard of proposed but later thro
On Wed, Nov 7, 2012 at 2:42 PM, Simon Pieters wrote:
> I think we shouldn't put the parsing algorithm on a pedestal while not
> giving the same treatment to the default UA style sheet or other
> requirements related to an element that have to be implemented.
The difference between the parsing alg
On Wed, 07 Nov 2012 13:25:14 +0100, Jirka Kosek wrote:
Changing parsing each time also means that such changes can't be undone.
They can be undone if doing so doesn't break the Web.
Look for example at . It's supported by parsing algorithm as
implemented in browsers, so it will remain in sp
On 7.11.2012 13:13, Simon Pieters wrote:
> If we were to design a system where we can make up new elements that go
> in one of those categories without changing the parser, I think we
> effectively have to put a magic string in the tag name, e.g. any element
> that starts with "block" is treated l
On Wed, 07 Nov 2012 12:55:46 +0100, Jirka Kosek wrote:
Changing parser each time new element is added is really evil idea and
sign of a bad design.
Parsing algorithm should be either not touched at all, or it should be
promptly changed to treat all unknown elements in other way if the
current
On Wed, Nov 7, 2012 at 12:55 PM, Jirka Kosek wrote:
> Changing parser each time new element is added is really evil idea and
> sign of a bad design.
HTML badly designed? Film at 11.
> Parsing algorithm should be either not touched at all, or it should be
> promptly changed to treat all unknown
On 7.11.2012 12:46, Simon Pieters wrote:
> I'm not convinced that we should freeze the parser now just because we
> have reached interop. I think not changing the parser here makes
> (and other future elements; whatever we do here sets a precedent for
> future elements) inconsistent with the res
On Wed, 07 Nov 2012 12:46:36 +0100, Simon Pieters wrote:
On Wed, 07 Nov 2012 11:40:57 +0100, Steve Faulkner
wrote:
Hi Anne,
That feedback as stated was mainly for Hixie, who dismissed it.
I have sought further opinion, but do not have the expertise to know
what I
need to do with it.
On Wed, 07 Nov 2012 11:40:57 +0100, Steve Faulkner
wrote:
Hi Anne,
That feedback as stated was mainly for Hixie, who dismissed it.
I have sought further opinion, but do not have the expertise to know
what I
need to do with it.
for example, I get the sense that implementers in general do
On Wed, 07 Nov 2012 10:54:19 +0100, Jirka Kosek wrote:
On 6.11.2012 23:18, Silvia Pfeiffer wrote:
* data-type: date, number, text etc which determines the comparison
function used in sort
It would be very difficult to support sorting on dates and numbers as in
HTML they are usually present
Hi Anne,
That feedback as stated was mainly for Hixie, who dismissed it.
I have sought further opinion, but do not have the expertise to know what I
need to do with it.
for example, I get the sense that implementers in general do not want to
mess with the parsing algorithm, so does that mean. I
I'm the author of http://www.kryogenix.org/code/browser/sorttable/, a
moderately popular JavaScript table sorting script. As such, I have about
nine years worth of anecdata about how authors want their HTML tables to be
sorted, the sorts of things they request, and issues that may be worth
taking i
On Wed, Nov 7, 2012 at 10:55 AM, Steve Faulkner
wrote:
> Can anyone with the requisite knowledge provide advice on what needs to be
> added (if anything) to the main element spec to define parsing for the
> element?
What did you do with the feedback you already got on this front?
http://lists.w3
Hi all,
After discussions with various implementers there appears to be some
questions about the main element and the parsing algorithm
Can anyone with the requisite knowledge provide advice on what needs to be
added (if anything) to the main element spec [1] to define parsing for the
element?
On 6.11.2012 23:18, Silvia Pfeiffer wrote:
> * data-type: date, number, text etc which determines the comparison
> function used in sort
It would be very difficult to support sorting on dates and numbers as in
HTML they are usually present formatted using specific locale. So there
should be addit
On Wed, Nov 7, 2012 at 8:37 PM, Jirka Kosek wrote:
> On 6.11.2012 23:18, Silvia Pfeiffer wrote:
>
> > * data-type: date, number, text etc which determines the comparison
> > function used in sort
>
> It would be very difficult to support sorting on dates and numbers as in
> HTML they are usually
38 matches
Mail list logo
