| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
svn path=/trunk/libcss/; revision=5760
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5759
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5758
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5676
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5675
|
|
|
|
|
|
| |
Make lexer, core parser, and css21 parser constructors&destructors return errors
svn path=/trunk/libcss/; revision=5674
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5648
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5647
|
|
|
|
|
|
| |
This is delightful. I get to rework the lexer state machine. Grr.
svn path=/trunk/libcss/; revision=5646
|
|
|
|
|
|
|
|
|
|
| |
Use this in font-weight parsing.
TODO: NUMBER tokens may contain [-+]? ([0-9]+ | [0-9]* '.' [0-9]+). The lexer currently doesn't cater for the [-+]? part. This is a bug (inherited from the grammar in the spec), and must be fixed.
TODO: integer_from_css_string probably wants to pass out the number of characters processed so that the client can determine if the input was valid for their context.
svn path=/trunk/libcss/; revision=5645
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5644
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5643
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5642
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5641
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5640
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5639
|
|
|
|
|
|
| |
display
svn path=/trunk/libcss/; revision=5638
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5637
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5636
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5635
|
|
|
|
|
|
|
|
| |
{top,right,bottom,left}
s/parse_length_specifier/parse_unit_specifier/g
Fix error propagation in some cases.
svn path=/trunk/libcss/; revision=5634
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5633
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5630
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5628
|
|
|
|
|
|
|
|
|
|
| |
Split out !important parsing into a separate function.
Support for dumping bytecode to a file handle in some kind of human-readable format.
Strings can be represented in the bytecode as a pointer, length pair rather than embedding the string data into the bytecode -- all strings are interned by the core syntax parser.
Add todo relating to early destruction of parser object (it shouldn't be needed once parsing is complete). Note documented issue surrounding interned string dictionary, however.
In general, it seems wasteful to create a new dictionary containing string representations of keywords for every single parser instance. It would be better to have one central (statically allocated?) dictionary for this and then each parser instance can have a smaller dictionary containing any unknown strings contained within the stylesheet being parsed (e.g. string constants or URLs).
svn path=/trunk/libcss/; revision=5627
|
|
|
|
|
|
| |
Provide API to create/destroy css_styles and append them to css_rules.
svn path=/trunk/libcss/; revision=5625
|
|
|
|
|
|
| |
Fix typos.
svn path=/trunk/libcss/; revision=5624
|
|
|
|
|
|
| |
Some type-related pedantry, too.
svn path=/trunk/libcss/; revision=5623
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5621
|
|
|
|
|
|
| |
Stub out handlers for properties.
svn path=/trunk/libcss/; revision=5620
|
|
|
|
|
|
| |
10 bits for the opcode and 8 for flags.
svn path=/trunk/libcss/; revision=5619
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5618
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5617
|
|
|
|
|
|
|
| |
This has been achieved by reducing opcode's width from 16 to 8 bits. This is fine as there's 172 opcodes still available at present so plenty of room for expansion. Flags have been reduced from 16 to 10 bits wide and currently have 8 bits unused. This leaves 14 bits available for the opcode-specific value. No opcode needs all 14 bits at present.
Inherit is now a global flag rather than a pre-defined value. This saves looking at the value field at all when styles are inherited and generally reduces complexity.
svn path=/trunk/libcss/; revision=5616
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5615
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5611
|
|
|
|
|
|
| |
selectors in the ruleset. Therefore, hang it off the css_rule object, rather than having a separate copy for every selector in the ruleset. Selectors know which css_rule they belong to so can easily find the applicable style information.
svn path=/trunk/libcss/; revision=5609
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5606
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5605
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5604
|
|
|
|
|
|
|
|
| |
-- combinators may be preceded by whitespace.
Fix handling of whitespace after a selector list: again, the CSS 2.1 grammar isn't accurate here.
svn path=/trunk/libcss/; revision=5603
|
|
|
|
|
|
| |
Make the css21 test driver call this so we can see if it's working.
svn path=/trunk/libcss/; revision=5602
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5599
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5597
|
|
|
|
|
|
| |
Media type handling may need to change -- 32bits may not be large enough in the long term, and there's no sensible way of extending this without causing ABI breakage in the future.
svn path=/trunk/libcss/; revision=5439
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5438
|
|
|
|
|
|
| |
frontend. This probably wants reworking as we don't really want to be switching on the language level every time we want to interact with the parser frontend.
svn path=/trunk/libcss/; revision=5437
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5436
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5435
|
|
|
|
| |
svn path=/trunk/libcss/; revision=5434
|