Michel Fortin wrote:
I know that. But special parsing rules, just as new CSS properties,
need changes to happen in the browser. If someone is going to improve
the browser, it'd be much better to improve the presentational layer
with a few reusable CSS rules than to add a collection of
Alexey Feldgendler wrote:
border-character isn't going to work. When scaled non-proportionally,
characters get ugly, with horizontal elements getting thick. The { and }
characters will suffer the most from this. TeX applies custom logic to
stretchy braces, and I think we shouldn't try
Michel Fortin wrote:
Le 20 juin 2006 à 6:53, Robert O'Callahan a écrit :
I would also like to see a complete description of the CSS extensions
required for real high-quality rendering.
I can't claim this is complete, but two ideas come to my mind right now:
[4 suggestions]
Also, as far as
Le 22 juin 2006 à 3:52, White Lynx a écrit :
Adding CSS extensions makes sense, but I fear it could take
infinite time,
therefore it is better to keep markup within XML/CSS2.1 framework
so we could
start using it today and then gradually improve situations on CSS
side.
It will surely
Based on the fedback recently received about how to do spellchecking in
HTML, here's a second proposal that uses an attribute to control it.
Comments? (Don't worry about typos and other such minor mistakes.)
AUTHOR REQUIREMENTS
textarea and input elements may have a new attribute specified,
On Thu, 22 Jun 2006, David Hyatt wrote:
If the user wants spell checking on in all textareas, then it should be on,
regardless of what the page says. I don't think the page should be allowed to
override spell checking rules, since this is really a user decision.
Agreed; the spec is written
If the user wants spell checking on in all textareas, then it should
be on, regardless of what the page says. I don't think the page
should be allowed to override spell checking rules, since this is
really a user decision. For example, I know how to spell, so I don't
want spell checking
On Thu, 22 Jun 2006, David Hyatt wrote:
The only time spell checking matters is when the user is the one
creating the content (not the author). It doesn't make any sense to
spell check non-editable content that the user didn't even create. If
the content is editable, then spell checking
The only time spell checking matters is when the user is the one
creating the content (not the author). It doesn't make any sense to
spell check non-editable content that the user didn't even create.
If the content is editable, then spell checking should just be left
up to the preference
The values of globalCompositeOperation are very poorly defined:
http://www.whatwg.org/specs/web-apps/current-work/#globalcompositeoperation
Some math is probably needed; prose alone seems unlikely to be
sufficient.
I made a quick test at:
http://dbaron.org/tests/canvas/composite-operations
Ian Hickson wrote:
textarea and input elements may have a new attribute specified,
spellcheck. If specified, it must have either the value on or the
value off (exactly, case-sensitive). The on value indicates that
spellchecking is to be enabled, the off value indicates that
spellchecking is to
On Thu, 22 Jun 2006, L. David Baron wrote:
The values of globalCompositeOperation are very poorly defined:
http://www.whatwg.org/specs/web-apps/current-work/#globalcompositeoperation
Some math is probably needed; prose alone seems unlikely to be
sufficient.
I agree; indeed I think there's
12 matches
Mail list logo
