Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
We already have it that way for rows < 1, but not for when rows was not
specified.
|
|
|
|
I generally tried to:
- start with a capital letter.
- end with a period.
- put elements inside <>.
- bring element names close to the beginning of the message.
|
|
Now no extra line at the bottom of the bugs, plus shorter strings.
|
|
|
|
|
|
|
|
|
|
May happen with ill formed HTML.
|
|
|
|
|
|
|
|
dw::core::ImgRenderer, not dw::Image (which now implements the former) anymore.
|
|
|
|
|
|
...now that there's tel, url, email, datetime, date, month, week, time,
datetime-local, number, range, color (all of which I imagine we will
continue to regard as 'text').
|
|
This patch avoids a family of problems that arise from handling nested inputs.
from invalid memory access up to crashes.
e.g. details in bof-read-47_attachView.html.asan.
This patch is much wider than the above referred instance.
|
|
It is said that this is typically only useful when OPTGROUP is working
(OPTGROUP gives context, and label will be something shorter than the
OPTION's contents).
It is also said that browsers don't or didn't tend to use an OPTION's label.
*shrugs*
|
|
I wrote nearly all of this last year, and I've just been going back over it
now. As I recall, I initially also tried: select holds optgroups and options,
and optgroups hold options (instead of this flat array of options, optgroups,
and close-optgroups), but the code wasn't coming out any cleaner, so...
|
|
|
|
I was just looking at distrowatch, and noticed that a menu looked odd.
It turns out that their code goes like
Amarok Live<option value="amaroklive">Amarok Live</option>
Amber<option value="amber">Amber</option>
Ankur Bangla<option value="ankur">Ankur Bangla</option>
Annvix<option value="annvix">Annvix</option>
AnNyung<option value="annyung">AnNyung</option>
Anonym.OS<option value="anonymos">Anonym.OS</option>
for some crazy reason. This led to dillo showing labels like
"AnNyung Anonym.OS".
|
|
To fix box colors...
|
|
Unilaterally changing user data is consistently a bad idea, but when browser
users aren't given any idea what they are permitted to type, it's better than
leaving out the chars, or replacing with '?' or whatever.
|
|
|
|
As of a couple of years ago, there was talk and confusion over whether
rfc 2231 should be used, or rfc 2047. But now... *sigh*
|
|
|
|
This had been discussed a bit a few years ago. At the time, the html4 spec's
idea was that you probably should require one but that implementations varied
on the details.
These days, firefox doesn't, and html5 mostly tells you not to (and is clear
that you can deselect the only selected one). (The world's biggest document,
practically a browser written in english at the instruction level, and it
still has many cases that aren't considered and spelled out carefully at this
point.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
(span, div, select, button)
|
|
Properly separate common image handling functions in CSS relevant
attribute parsing (a_Html_image_attrs) and image creation
(a_Html_image_new()).
This should also bring the code back a bit to what we had before
8214199c2703.
|
|
|
|
Basically, I and i are different letters in Turkic languages, and this
causes problems for str(n)casecmp and toupper/tolower in these locales
when dillo is dealing with ASCII.
|
|
bug #1018 submitter requested behaviour a little more
friendly to html5, which sounds sensible as bits of
that infinite monstrosity start showing up more
often...
|
|
ComplexButtonResource was creating endless redraws.
Testcase:
<table>
<tr>
<td>
<div>
<button></button>
</div>
<div>
words words words words words words words words words words words
words words words words words words words words words words words
words words words words words words words words words words words
words words words words words words words words words words words
<span style="white-space:nowrap">And words in a span</span>
<button></button>
</div>
</td>
</table>
This also fixes redraw loops with <button> in combination with
limit_text_width=YES, so we no longer need to disable this option.
Reported and testcase by: corvid <corvid@lavabit.com>
|
|
|
|
http://lists.auriga.wearlab.de/pipermail/dillo-dev/2010-March/007408.html
http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-May/008319.html
|
|
|
|
* Instead of passing the nonCssHints as a CssPropertyList, set the hints
separately and create the list in StyleEngine.
* The CssPropertyList holding the nonCssHints is now completely managed
by StyleEngine and kept on the stack.
* Replace the table_cell_props mechanic in html.cc/table.cc with a
new method inheritNonCssHints() in StyleEngine.
|