On Tue, Oct 1, 2013 at 8:45 PM, Ian Hickson i...@hixie.ch wrote:
Crashing is non-conforming.
rules-lawyer
href=http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#conformance-requirements;
Terminating the process with SIGSEGV if a page exceeds an
On Wed, Dec 19, 2012 at 10:49 PM, Ian Hickson i...@hixie.ch wrote:
How common is it for a part of a page to be editable when the page is
loaded, for there to be no formatting UI, for the page to not mind if the
user uses the browser's own formatting features (e.g. dragging and
dropping
On Thu, Oct 18, 2012 at 1:23 AM, Ian Hickson i...@hixie.ch wrote:
Incidentally, it seems to use a WebKit-specific plaintext-only value.
Should we spec that? Aryeh? It's filed as:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14554
If this should involve changes to HTML, let me know.
In
On Thu, Sep 6, 2012 at 6:30 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Note that this shouldn't be hard to do without magic. Just something
like this in the UA style sheet:
[contenteditable]:empty { min-height: 1em; }
contenteditable is not a boolean attribute -- you'd need to do
On Sat, Sep 1, 2012 at 4:22 AM, David Young dyo...@pobox.com wrote:
This demonstrates some unexpected contenteditable results on
Chrome 21.0.1180.82 under Mac OS X. I cannot seem to return the
contenteditable to the empty state again---i.e., to the state where the
placeholder shows---using
On Wed, Sep 5, 2012 at 10:37 PM, David Young dyo...@pobox.com wrote:
I have to say that I'm uneasy with the way that this API wavers between
answering interaction-design questions and telling what ought to happen
to the DOM under, say, an execCommand('insertText'). Just for example,
lots of
On Thu, Aug 2, 2012 at 9:42 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 26 Jul 2012, Smylers wrote:
Ian Hickson writes:
Also, I do not understand why we have credit cards types. Is anyone
willing to have his credit cards information saved locally?
Sure, why not?
I am too, but I can
On Tue, Jul 24, 2012 at 2:41 AM, Ian Hickson i...@hixie.ch wrote:
Are there any common fields missing from the list above?
Government-issued ID numbers might be worth adding. In America,
social security numbers are sometimes used for this purpose, but are
treated as semi-secret, so you usually
On Thu, Jul 26, 2012 at 11:52 AM, Smylers smyl...@stripey.com wrote:
Perhaps specifying certain autocomplete types could set defaults for
pattern and inputmode? So for this example autocomplete=cc-num would, if
pattern isn't specified, imply pattern=\d{16}, and equivalently for
inputmode?
On Thu, Jun 14, 2012 at 1:11 AM, Ian Hickson i...@hixie.ch wrote:
I strongly disagree. input and textarea are high-level constructs, so
it's fine for them to be defined by the UA's platform. But contenteditable
is a very low-level primitive. We can't just punt on how it interacts with
CSS;
On Thu, May 10, 2012 at 10:58 AM, Edward O'Connor eocon...@apple.com wrote:
The srcset= attribute takes as its argument a simplified variant of
the image-set() microsyntax[2]. It would look something like this:
img src=foo-lores.jpg
srcset=foo-hires.jpg 2x, foo-superduperhires.jpg 6.5x
On Thu, May 10, 2012 at 2:44 PM, Edward O'Connor eocon...@apple.com wrote:
I'm not sure about this one. If a browser doesn't support SVG, I want to
be able to provide a bitmap fallback regardless of how I included the
SVG—in both the img src or inline svg element cases. img srcset
isn't about
On Wed, May 2, 2012 at 8:00 AM, Ryosuke Niwa rn...@webkit.org wrote:
Hi,
Would it be useful to have placeholder content attribute on elements that
are editable? (i.e. contenteditable=true).
According to the original WebKit bug
21286https://bugs.webkit.org/show_bug.cgi?id=21286,
this may
On Wed, May 2, 2012 at 9:59 AM, Ryosuke Niwa rn...@webkit.org wrote:
Great. I think the tricky part will be defining exactly how and when the
placeholder is displayed.
e.g. Should it be treated as if there is a text node in the editable
element? Should we ignore things like br or collapsible
On Mon, Apr 30, 2012 at 5:35 PM, David Young dyo...@pobox.com wrote:
I have seen this spec before. It seems to have something to do
with creating a word processor-like environment in the browser,
something that I am acutely interested in, but there isn't much
introduction/justification to it.
On Sun, Apr 29, 2012 at 10:29 AM, Ryosuke Niwa rn...@webkit.org wrote:
That sounds like a tangential issue. We can easily extend execCommand to
support arbitrary range(s) since such a feature is also valuable in richly
editable areas.
Ranges don't exist in plaintext areas. How would you get a
On Sun, Apr 29, 2012 at 11:39 PM, David Young dyo...@pobox.com wrote:
I'm curious what advantages document.execCommand() has over the
customary DOM API for adding/deleting/moving nodes?
execCommand() does vastly more complicated things than the DOM APIs.
See the spec for details:
On Fri, Feb 10, 2012 at 10:37 AM, Boris Zbarsky bzbar...@mit.edu wrote:
I agree that having the list for lengths reduces the scope of the problem
somewhat. But the color quirk means that any shorthand that includes colors
will run into ambiguity issues if any keywords for any subproperty only
On Thu, Jan 12, 2012 at 12:46 PM, Francis Boumphrey
boumphre...@gmail.com wrote:
e.g. video src='myvideo.mp4' controls
and my user agent does not support the format, all I get (in my versions of
Opera and Firefox) is a blank screen. No message (as I would get with
embed) and as far as I can
On Fri, Nov 25, 2011 at 11:06 PM, Boris Zbarsky bzbar...@mit.edu wrote:
It would break existing pages that use expandos on elements or documents via
barewords in on* attributes.
Isn't that the point of look at element's named properties (if it has
any) and look at element's form's named
On Mon, Nov 21, 2011 at 11:43 PM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
However, I don't think this rough classification actually helps me
much to identify what I want to look at. If at least the area of
change is mentioned in your descriptive text, that would help me much
more. For
On Mon, Nov 7, 2011 at 8:03 PM, Ryosuke Niwa rn...@webkit.org wrote:
* The author must not be forced to deal with manually handling DOM
state just because they want to handle non-DOM state.
I disagree with this requirement. This should be an opt-in feature, not
something forced upon authors.
On Tue, Nov 8, 2011 at 4:48 AM, Jonas Sicking jo...@sicking.cc wrote:
Yup, that seems like the right solution. But we should specify exactly
what the UA should store. I.e. should it store the whole before/after
values? What should it do if the after-value doesn't match the current
value when
On Tue, Nov 8, 2011 at 11:55 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Nov 8, 2011 at 6:12 AM, Aryeh Gregor a...@aryeh.name wrote:
Yeah, it'll be nice if we could define the behavior precisely but then
again, there's nothing that prevents authors from modifying DOM in any
arbitrary
Oops, Gmail's new look is confusing me. I did Reply instead of Reply
to all. Resending. Ryosuke, you replied off-list, so you should
probably repeat the reply on-list.
On Tue, Nov 8, 2011 at 11:39 AM, Ryosuke Niwa rn...@webkit.org wrote:
The value of input and textarea elements isn't
On Tue, Nov 8, 2011 at 12:44 PM, Ryosuke Niwa rn...@webkit.org wrote:
I don't think adding noundo solve this problem.
I agree, I abandoned that idea a while ago. It only makes sense if
undo undoes all DOM changes, even if they're outside a transaction.
Otherwise it's pointless. I didn't
(sorry for the long delay in responding, life is sometimes flaky for
me right now)
On Fri, Oct 28, 2011 at 3:54 PM, Ryosuke Niwa rn...@webkit.org wrote:
But that manual transaction may be mutating DOM outside of the editable
region. i.e. in the slide app case, you may have plane that's showing
Okay, I created a wiki page with use-cases and requirements for them:
http://wiki.whatwg.org/wiki/UndoManager_Problem_Descriptions
I based it off http://rniwa.com/editing/undomanager-usecases.html,
plus posts in this thread. I think that the current spec does not
fulfill the following
On Thu, Oct 27, 2011 at 6:10 PM, Jonas Sicking jo...@sicking.cc wrote:
Why is it harder to remember one function name and one attribute name,
than to remember to function names?
Because the function names in this case must be in your code and they
must be correct, or they won't work. That
On Fri, Oct 28, 2011 at 3:06 AM, Jonas Sicking jo...@sicking.cc wrote:
I'm not sure what you are trying to say.
I think he means to say that custom IDL properties added by authors
have to persist. I'm not sure there's any official name for them in
standards, but I've heard them called expando
On Fri, Oct 28, 2011 at 12:07 PM, Mike Taylor
michaelaarontay...@gmail.com wrote:
I would prefer if it returned the DOMTokenList, to enable chaining like:
foo.toggle('bar baz').remove('bat');
Same for the rest of the DOMTokenList methods, as well.
foo.add('bar').remove('baz');
See
On Fri, Oct 28, 2011 at 12:59 PM, Ryosuke Niwa rn...@webkit.org wrote:
I don't want string because then I'd have to do:
if (mode == 'reapply')
instead of
if (isReapply)
and the former is much more verbose.
It's a few extra characters. I really think the increase in clarity
is worth it.
On Fri, Oct 28, 2011 at 2:47 PM, Ojan Vafai o...@chromium.org wrote:
On Fri, Oct 28, 2011 at 11:36 AM, Aryeh Gregor a...@aryeh.name wrote:
It's a few extra characters. I really think the increase in clarity
is worth it. Boolean parameters are much more confusing, and should
be avoided
On Wed, Oct 26, 2011 at 2:39 PM, Ryosuke Niwa rn...@webkit.org wrote:
I meant properties authors added to nodes. e.g.
span.myProperty = true;
Should span be removed by some automatic transaction, authors may expect it
to be restored on undo.
That sounds like the ideal behavior, unless it's
On Thu, Oct 27, 2011 at 2:28 PM, Ojan Vafai o...@chromium.org wrote:
I disagree. I think the boolean makes things more complicated. Boolean
arguments stink. Every time you want to use this API you need to go look up
the documentation to remember whether the boolean is isReapply or
isApply.
Things I noticed while reading through it, leaving aside editorial
nitpicks that wouldn't improve clarity:
1) I was confused at first by the fact that undo goes backward in the
history, and redo goes forward. I would have expected that new
transactions are added to the end of the list, not the
On Wed, Oct 26, 2011 at 1:13 PM, Ryosuke Niwa rn...@webkit.org wrote:
This is so that the last transaction is always at position 0, and applying a
new transaction does not move the position. The position is non-zero only if
we have not applied any new transactions and have done undo.
Makes
On Thu, Oct 20, 2011 at 3:16 AM, Ryosuke Niwa rn...@webkit.org wrote:
However, there's no easy way for the user agent to figure out whether a
given transaction wants to select some contents on undo or not. In fact, we
don't even know whether we want to restore selection at all. If an automatic
On Wed, Oct 26, 2011 at 4:03 PM, Ehsan Akhgari eh...@mozilla.com wrote:
Say you had hello world and world is deleted by an user. When the
user undoes the deletion, WebKit selects world whereas Firefox and
Internet Explorer do not select world. WebKit's behavior matches
Mac's NSTextView and we
On Wed, Oct 26, 2011 at 4:25 PM, Glenn Maynard gl...@zewt.org wrote:
No text is selected, the user hits control-backspace, and then undo. The
restored word world now may or may not be selected, depending on the UA
and platform.
Ah, okay. Got it.
On Tue, Jun 28, 2011 at 1:38 PM, Aryeh Gregor simetrical+...@gmail.com wrote:
I've updated the spec to require this:
https://bitbucket.org/ms2ger/dom-range/changeset/b9ca1640aeee
http://html5.org/specs/dom-range.html#apis-for-the-browsing-context-selection:-the-selection-interface
On Mon, Oct 10, 2011 at 9:32 PM, Ryosuke Niwa rn...@webkit.org wrote:
Allowing authors to define an undoscope inside an editing host appears to be
troublesome because user editing actions can modify the subtree of the host
in very complex ways, and it's hard to understand which node may be
On Tue, Oct 11, 2011 at 12:58 PM, Ryosuke Niwa rn...@webkit.org wrote:
It also means you can't support :read-write for contenteditable, because
that
would make selectors depend on style resolution. Is it just a
convenience measure so that you don't have to implement efficient
property
On Wed, Sep 28, 2011 at 11:00 AM, Rob Crowther robe...@boogdesign.com wrote:
I think this is exactly what this StackOverflow user was asking for:
http://stackoverflow.com/questions/7548612
Basically he wants to trigger validation for each section of the form as the
user goes along.
Doesn't
On Mon, Sep 26, 2011 at 12:34 PM, Ryosuke Niwa rn...@webkit.org wrote:
No. The property is platform dependent. It's just that UAs on Windows and
Linux don't use none in most cases.
Do they ever use it?
On Tue, Sep 20, 2011 at 10:13 PM, Ryosuke Niwa rn...@webkit.org wrote:
void apply(in boolean isReapply)
I haven't been following the substance of apply vs. reapply etc., but
as I said before, could you not make this a boolean argument? How are
authors supposed to remember whether it's
On Wed, Sep 21, 2011 at 12:58 PM, Ryosuke Niwa rn...@webkit.org wrote:
So apply, unapply, and reapply are callback functions supplied by authors
and called by UAs.
e.g.
myUndoScope.undoManager.transact({
apply: function() {alert('done');},
unapply: function() {alert('undone');},
On Mon, Sep 19, 2011 at 12:37 PM, Ryosuke Niwa rn...@webkit.org wrote:
Not throwing makes sense to me (at least for now). What value should they
return though?
State/indeterm should return false, value should return . For
state/indeterm, this is what IE/WebKit/Opera do (Gecko throws). For
On Mon, Sep 19, 2011 at 1:50 PM, Ryosuke Niwa rn...@webkit.org wrote:
Sounds like a reasonable solution to me. For what's worth, I think WebKit
used to return false all the time so I don't think this will cause a huge
compat. issue for us.
I've changed the spec (warning, large diff):
On Thu, Sep 15, 2011 at 6:34 PM, Ehsan Akhgari eh...@mozilla.com wrote:
Maybe we can split these tests into multiple files, with one master file
which loads them all, one by one, in iframes or something?
I just tried running them under a debug build of Firefox, and they take
about three times
I'm still using the whatwg list, because discussion on whether using
public-webapps is okay is (of course) still ongoing:
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1402.html
What should the correct behavior be in the following cases?
* queryCommand*(insertimage). Neither
On Fri, Sep 9, 2011 at 12:48 PM, Bjartur Thorlacius
svartma...@gmail.com wrote:
It freezes surf as well, and then crashes it (though that's clearly a bug in
surf and maybe JavaScriptCore). Opera runs it fine, but the chrome is slowed
down severely. The results are quite a bit bigger than my
On Mon, Sep 12, 2011 at 8:19 PM, Jonas Sicking jo...@sicking.cc wrote:
Could you please supply an example where the apply/reapply split leads
to cleaner or otherwise better code than using a boolean argument?
Boolean arguments are evil and should be avoided wherever possible.
It's impossible to
I've had some type of tests around for a while now, but they weren't
suitable for implementers. I've now recoded and reformatted them so
that they output a table of results using James Graham's
testharness.js. The link is here, but WARNING: it will run script
continuously for a few minutes,
On Tue, Aug 30, 2011 at 12:12 PM, Ryosuke Niwa rn...@webkit.org wrote:
Mn... I've never had that problem. e.g. .net framework uses the term
managed code to mean the code that's garbage-collected by the framework
and unmanaged code to mean the code that manually manage memory among
other
In the UndoManager spec http://rniwa.com/editing/undomanager.html,
there are two types of transactions: managed and manual. Managed
transactions are handled by the browser, while manual ones are handled
by the author. The term managed keeps confusing me, though. I
never remember if it means
On Sun, Aug 28, 2011 at 12:26 AM, Jukka K. Korpela jkorp...@cs.tut.fi wrote:
The word void, though used even in the validator's message, is at least
misleading if not incorrect. The correct word is empty.
Void is correct:
2011/8/18 Alfonso Martínez de Lizarrondo aml...@gmail.com:
Showing all whitespace would be the most complete solution, but if the rest
of browsers could behave like Opera and handle this, that would be enough
for most of the people:
br:before {content: \B6;}
That doesn't sound like a great
Thanks again for your feedback.
2011/8/16 Alfonso Martínez de Lizarrondo aml...@gmail.com:
Ups, sorry, I thought that the Comments buttons would open a feedback form
but anyway I haven't read all the spec and I just used Ctrl+F to check for
some of those commands and I didn't find anything.
On Wed, Aug 17, 2011 at 4:12 AM, Alexandre Morgaut
alexandre.morg...@4d.com wrote:
I like the idea of a declarative way to support autosuggestions
OpenSearch already made a successful specification supported by most browsers
http://www.opensearch.org/Specifications/OpenSearch/1.1
That's an
2011/8/16 Alfonso Martínez de Lizarrondo aml...@gmail.com:
Hi
The drafted specs defines most of the common features of contentEditable,
but there are other commands that have been left out
enableInlineTableEditing
enableObjectResizing
AutoUrlDetect
RespectVisibilityInDesign
...
I have
On Sun, Aug 14, 2011 at 3:26 AM, Timo Beermann
timo.beerm...@googlemail.com wrote:
The search-suggestions of search-fields as in Google or Wikipedia
should be able without scripting, only with HTML/CSS. Because some
users deactivate Scripting (for security or whatever other reason) and
on
On Mon, Aug 8, 2011 at 5:03 AM, Simon Pieters sim...@opera.com wrote:
Things that are visibility:hidden are not focusable. I don't think that can
be changed without compat problems. If visibility:hidden things are not
focusable, I guess it makes sense to not make it selectable, too. (Possibly
On Fri, Aug 5, 2011 at 1:57 AM, Jonas Sicking jo...@sicking.cc wrote:
It would make sense to me to match ES here. The main concern is of
course website compat. Could someone detail what the differences would
be compared to what implementations/the HTML5 spec do now?
As far as I know, the only
On Thu, Aug 4, 2011 at 5:22 PM, Ryosuke Niwa rn...@webkit.org wrote:
I see. It's an interesting point. In WebKit, we're quite inconsistent in
relying on CSS/rendering engine and pure DOM. This is an inherent issue in
RTE because user would like the editor to work like WYSIWYG yet we have to
On Tue, Aug 2, 2011 at 8:31 PM, Ryosuke Niwa rn...@webkit.org wrote:
I've read a part of sections 7 and 8 but I've kind of lost here. The spec
is very detailed and I can't really get a high-level view of what will
happen. It might be helpful to have some high-level summary of what it
tries
On Wed, Aug 3, 2011 at 5:06 PM, Ehsan Akhgari eh...@mozilla.com wrote:
On 11-08-03 4:13 PM, Aryeh Gregor wrote:
Mike Smith has been kind enough to add a component to the W3C Bugzilla
for the editing spec, in the WebApps WG product. From now on I'll use
it for tracking feedback so I can
Hixie just WONTFIXed two bugs that I thought might be of interest:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12220
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12296
Basically, HTML defines some algorithms for parsing integers, floats,
etc., which are used in converting DOM to IDL
Mike Smith has been kind enough to add a component to the W3C Bugzilla
for the editing spec, in the WebApps WG product. From now on I'll use
it for tracking feedback so I can be organized about things that I
can't fix right away. The link to file a bug is:
On Tue, Jul 26, 2011 at 5:26 PM, Aryeh Gregor simetrical+...@gmail.com wrote:
Anyone reviewing the spec should be advised that I put extensive
rationale in HTML comments. If you want to know why the spec says
what it does, check the HTML source. I plan to change this to use
details
On Fri, Jul 29, 2011 at 9:53 PM, Bjartur Thorlacius
svartma...@gmail.com wrote:
So there are two use cases for reading user passwords:
* client side password strength indicators
** telling users if their passwords conform to site specific password
restrictions
- arguably bad practice
-
On Fri, Jul 29, 2011 at 7:24 PM, Ian Hickson i...@hixie.ch wrote:
My overarching point, however, is that this is a UI issue, and not an
authoring issue.
The overarching counterpoint is that in-page UI *is* an authoring
issue, because authors want to control exactly how their page looks
and
On Fri, Jul 29, 2011 at 11:13 AM, Dan Gisolfi giso...@us.ibm.com wrote:
On behalf of the Open Cooperative Web Framework Project
(http://opencoweb.org), with respect to the HTML Editing APIs specification
(http://aryeh.name/spec/editing/editing.html), it would seem the current
version of the
On Wed, Jul 27, 2011 at 7:51 PM, Ryosuke Niwa rn...@webkit.org wrote:
WebKit treats any font-weight above or equal to 600 as bold because that's
what user sees, and boldness is a binary concept in execCommand; Firefox 5
appears to do the same.
WebKit compares colors in rgb/rgba format; e.g.
On Fri, Jul 29, 2011 at 5:51 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Jul 29, 2011 at 9:43 AM, Ian Hickson i...@hixie.ch wrote:
Looking specifically at datagrid's ability to fall back to select, I
agree that it's not necessarily doing to be widely used, but given that
it's so simple
On Wed, Jul 27, 2011 at 6:55 PM, Tim Down timd...@gmail.com wrote:
There's also the perennial problem of dealing with non-visible text
(c.f. Selection.toString(), innerText), which some browsers handle (a
quick tests suggests WebKit searches non-visible text and Firefox
doesn't).
True. Of
Thanks to both of you for the feedback!
On Wed, Jul 27, 2011 at 7:51 PM, Ryosuke Niwa rn...@webkit.org wrote:
WebKit treats any font-weight above or equal to 600 as bold because that's
what user sees, and boldness is a binary concept in execCommand; Firefox 5
appears to do the same.
Yes, bold
(Ian pointed out this old thread to me that he hadn't yet responded
to, so I'll respond now.)
On Thu, Jul 2, 2009 at 6:05 PM, Ryosuke Niwa rn...@google.com wrote:
Hi, I just realized that in HTML4.01 spec, DTD doesn't seem to allow
nested OL or UL without LI. See
(Responding to some old feedback on editing from before I started work
on it, which Hixie sent me.)
On Thu, Jun 24, 2010 at 12:08 PM, Nikita Vasilyev m...@elv1s.ru wrote:
The current version of spec
http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#contenteditable
does
(answering some old feedback on DOM Range that Hixie pointed me to)
On Tue, Jun 15, 2010 at 6:52 AM, Andrew Oakley and...@ado.is-a-geek.net wrote:
I've been trying to implement DOM Range but can't work out how ranges
are supposed to work under mutation.
This should now be more or less fully
Since February, I've been working on writing a detailed specification
for browser editing, primarily the document.execCommand() and
document.queryCommand*() methods. These were created by Microsoft in
the 1990s and were subsequently adopted in some form by all other
browsers, and today browsers
On Wed, Jul 20, 2011 at 6:23 PM, Tim Down timd...@gmail.com wrote:
Yes, but it's significantly better than the alternative, which is to
write your own code to search for text that spans nodes.
It shouldn't be *too* hard to write that code. First do the search in
textContent and get a list of
On Wed, Jul 20, 2011 at 6:14 AM, Tim Down timd...@gmail.com wrote:
It's useful for custom search features. I've recommended it a few
times on Stack Overflow for people wanting to highlight or somehow
style all occurrences of a piece of text that may span nodes (it's
this part that is the
On Mon, Jul 18, 2011 at 10:33 AM, David Karger kar...@mit.edu wrote:
Yes, we could, but it doesn't address the two objections I raised to data-
prefix:
1. it isn't actually a data attribute, so prefixing with data seems odd
(appearance; minor)
It's data in the sense that it's being used to
On Mon, Jul 11, 2011 at 9:29 AM, Sean Connelly s...@pbwhere.com wrote:
As a web developer, if I wanted access to the password, I would then avoid
using the input type=password field, and create my own field that reads
characters (perhaps via onkeyup), and fakes a password field visually.
Then
On Fri, Jul 1, 2011 at 4:26 AM, Simon Pieters sim...@opera.com wrote:
blockquote is sectioning root.
Oops. I stand corrected, never mind me.
On Thu, Jun 30, 2011 at 11:50 AM, Oli Studholme whatwg@boblet.net wrote:
blockquote
p[block quote]/p
footer— citea href=…[title of work]/a/cite/footer
/blockquote
This is incorrect according to the current definition of footer.
Footer definition:
“The footer element represents a
On Fri, Jun 17, 2011 at 1:40 PM, Aryeh Gregor aryehgre...@gmail.com wrote:
However, I'd still like to normalize author-set selections somewhat.
At a minimum, for instance, we could guarantee that a selection's
boundary point is always in a Text or Element node that descends from
a Document
On Fri, Jun 24, 2011 at 10:52 PM, Robert O'Callahan
rob...@ocallahan.org wrote:
That's true if you call fillRect(), or fill() on a path that you've emitted
while the current matrix is singular; the rectangle or path collapses to a
single point (or line). I think it's completely clear browsers
On Thu, Jun 23, 2011 at 5:55 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
The implementation statuses are not automatically generated - they're
updated when someone cares enough to update them. Anyone can do so,
though it's not very discoverable. Hold down Ctrl+Alt and
double-click the
On Fri, Jun 24, 2011 at 1:09 AM, Robert O'Callahan rob...@ocallahan.org wrote:
Consider this testcase:
http://people.mozilla.org/~roc/SingularCanvasMatrix.html
It sets up a rectangle to fill, then sets the current matrix to a singular
matrix (yy=0 in this case), then fills with different
On Wed, Jun 22, 2011 at 11:50 AM, Edward O'Connor eocon...@apple.com wrote:
The second bit (does not apply to the element), however, isn't clear.
Is it a UA conformance requirement? What does it mean? I *think* it
means that the placeholder= attribute has no effect on the rendering
of input
On Mon, Jun 20, 2011 at 6:05 PM, Ryosuke Niwa rn...@webkit.org wrote:
Problem is that not all user agents, in particular, mail clients support
white-space: pre-wrap.
Good point. That's pretty much the final nail in the coffin. I'll
specify something with nbsp's here, although I don't know how
On Mon, Jun 20, 2011 at 5:09 PM, Aryeh Gregor simetrical+...@gmail.com wrote:
Does anyone have any suggestions on how best to handle this? It seems
like no matter what we do, the best advice to authors would be to set
white-space: pre-wrap on the editable region and the resulting
editable
If the user has the cursor positioned at the beginning or end of a
line, or immediately before or after a space, and hits space,
inserting a space at the current location would result in no visible
effect. Thus browsers will typically insert an nbsp in at least some
of these conditions, and/or
On Mon, Jun 20, 2011 at 5:32 PM, Ehsan Akhgari eh...@mozilla.com wrote:
There's a very good reason why existing browser engines have to resort to
nbsp; hacks. It's the only practical way to make sure that foo__bar
(s/_/ /) entered into an editable element would appear the intended way when
On Mon, Jun 20, 2011 at 4:40 AM, James Graham jgra...@opera.com wrote:
FWIW I disagree. The same argument could be used against client-side form
validation since some authors might stop doing proper server-side
validation.
I agree, HTML5 forms provide a minor net security loss. However, the
On Thu, Jun 16, 2011 at 5:39 PM, Daniel Cheng dch...@chromium.org wrote:
A variation of this idea has been proposed in the past but was largely seen
as undesirable--see
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-May/026254.html. In
general, I feel like the same objections are
Since I've somehow managed to send from the wrong address again for
the third time in 48 hours, here's yet another resent mail, probably
to be followed by a fourth when I respond to Boris' response and Gmail
auto-selects my non-list address again for the from address instead of
my list address:
On Thu, Jun 16, 2011 at 1:40 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
As a web developer, I agree - my intuitive understanding of @scoped is
that it makes matching *start* at the scoped element. That's what
scoped means. The other meaning is more like a filter.
Me too. I think it
1 - 100 of 513 matches
Mail list logo
